ES2423509T3 - Un terminal, un servidor y un método para gestionar dicho terminal y un método para comunicar la información de capacidad relativa a este terminal - Google Patents

Un terminal, un servidor y un método para gestionar dicho terminal y un método para comunicar la información de capacidad relativa a este terminal Download PDF

Info

Publication number
ES2423509T3
ES2423509T3 ES08871373T ES08871373T ES2423509T3 ES 2423509 T3 ES2423509 T3 ES 2423509T3 ES 08871373 T ES08871373 T ES 08871373T ES 08871373 T ES08871373 T ES 08871373T ES 2423509 T3 ES2423509 T3 ES 2423509T3
Authority
ES
Spain
Prior art keywords
terminal
capacity information
sip
capacity
message
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
ES08871373T
Other languages
English (en)
Inventor
Jian Yang
Guoqiao Chen
Ting Dong
Lei Wang
Shunan Fan
Huiping Zhang
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2423509T3 publication Critical patent/ES2423509T3/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/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/1066—Session management
    • H04L65/1073—Registration or de-registration
    • 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/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • 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/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método de gestión de terminal en un servicio de tipo Push, que comprende: enviar una demanda de información de capacidad del terminal a un terminal y recibir información de capacidad del terminal reenviada por el terminal y gestionar las capacidades del terminal según lainformación de capacidad del terminal; en donde la etapa de enviar la demanda de información de capacidad del terminal comprende: enviar la demanda deinformación de capacidad del terminal al terminal si se determina que ninguna información de capacidad del terminal delterminal está memorizada localmente o si se determina que la información de capacidad del terminal memorizadalocalmente está incompleta y en donde dicha demanda de información de capacidad del terminal transmite la información de capacidad del terminalobtenida y en donde dicha información de capacidad del terminal reenviada es una diferencia entre la información de capacidad delterminal actual del terminal y la información de capacidad del terminal transmitida en la demanda y en donde la etapa que consiste en gestionar las capacidades del terminal según la información de capacidad del terminalcomprende, además, actualizar la información de capacidad del terminal memorizada localmente en función de ladiferencia.

Description

Un terminal, un servidor y un método para gestionar dicho terminal y un método para comunicar la información de capacidad relativa a este terminal
CAMPO DE LA INVENCIÓN
La presente invención se refiere a una tecnología de servicio denominada Push y en particular, a un método de gestión de terminal en el servicio Push, un método de comunicación de información de capacidad relativa a este terminal en el servicio Push, un terminal que soporta el servicio Push y un servidor que soporta el servicio Push.
ANTECEDENTES DE LA INVENCIÓN
El servicio Push de Protocolo de Iniciación de Sesión (SIP) encapsula el contenido del protocolo de Push ‘a través del aire’ (OTA) en un mensaje SIP y utiliza la red central del protocolo de SIP/Internet (IP) existente para transmitir el mensaje SIP. La tecnología de OTA-SIP, para poner en práctica el servicio Push, está caracterizada por su bajo coste de mantenimiento, alta interoperabilidad, uso eficiente de los recursos de redes existentes y buena integración con el futuro entorno de red All-IP.
La Figura 1 representa un modelo, a modo de ejemplo, de la arquitectura de servicio Push de SIP. En esta arquitectura, se introducen un agente emisor Push y un agente receptor Push. El agente emisor Push y el agente receptor Push son módulos funcionales que sirven como puntos de acceso de red central de SIP/IP. Según se ilustra en la Figura 1, el agente emisor Push está situado en el lado del servidor, a modo de ejemplo, situado en una pasarela proxy Push (PPG) y el agente receptor Push está situado en el lado del cliente, esto es, en el lado del cliente de Push. P-1 y P-2 son puntos de referencia. El punto de referencia P-1 soporta la comunicación entre el agente receptor Push y la red central de SIP/IP y el punto de referencia P-2 soporta la comunicación entre el agente emisor Push y la red central de SIP/IP.
Antes de realizar un servicio (a modo de ejemplo, antes de iniciar un servicio al terminal), un servidor necesita conocer la información de capacidad del terminal de modo que el servidor pueda enviar información de servicio correcta al terminal en función de la información de capacidad del terminal. El documento US2006/179115A1 da a conocer que un método proporciona control de las operaciones Push en un sistema de comunicación. El método incluye la demanda de información de capacidades asociadas con un dispositivo de comunicación. La información de capacidades incluye una indicación de al menos un método Push soportado por el dispositivo de comunicación. El método recibe también la información de capacidades. El método decide también una forma para gestionar una operación Push hacia el dispositivo de comunicación en función de la información de capacidades. La información de capacidades puede memorizarse como una parte de información de presencia en relación con un usuario del dispositivo de comunicación. El documento EP1758300A1 da a conocer que un método de información a una red de un cambio de la capacidad del equipo del usuario comprende: detener el funcionamiento de un temporizador de registro en el lado del usuario establecido actualmente cuando cambia la capacidad del equipo del usuario, el envío de un mensaje de demanda de registro que transmite información de nueva capacidad del equipo de usuario a la red; el análisis, por la red, del mensaje de demanda de registro y la memorización de la información de nueva capacidad del equipo del usuario para referencia mediante un posterior establecimiento de una sesión. El cambio de capacidad se informa a la red a su debido tiempo.
Actualmente, el servidor obtiene y gestiona la información de capacidad del terminal principalmente a través de la comunicación por el terminal. El terminal puede comunicar su información de capacidad a la pasarela PPG en el proceso de suscripción. En el SIP Push, el terminal utiliza el mensaje SIP Subscribe y el mensaje SIP Notify para suscribir servicios y dichos mensajes transmiten la información de capacidad del terminal. Dicho proceso puede ponerse en práctica a través de un paquete de eventos operativos de perfil del agente del usuario (ua profile) del mensaje Subscribe. Según se ilustra en la Figura 2, el proceso incluye las etapas siguientes:
Etapa 1: El terminal envía una demanda de abono Subscribe a la red central de SIP/IP. La demanda transmite un paquete de eventos de perfil de ua profile, esto es, información de capacidad del terminal.
Etapa 2: Después de recibir la demanda de abono Subscribe, la red central de SIP/IP reenvía la demanda Subscribe al agente emisor Push.
Etapa 3: Después de recibir la demanda de abono Subscribe, el agente emisor Push gestiona la información de suscripción de servicio y la información de capacidad del terminal, a modo de ejemplo, demandas para obtener la información de capacidad del terminal desde el perfil ua profile y memoriza directamente la información de capacidad del terminal. En adelante, el agente emisor Push envía una respuesta 200 OK a la red central de SIP/IP.
Etapa 4: La red central de SIP/IP reenvía la respuesta 200 OK al agente receptor Push.
A través del proceso anterior en la técnica convencional, el terminal comunica su información de capacidad al servidor. Existen al menos los siguientes problemas en la técnica convencional: después de que el terminal comunique su información de capacidad, la información de capacidad del terminal puede cambiarse, a modo de ejemplo,
actualizándose el software en el terminal. En este caso, el servidor es incapaz de actualizar la información de capacidad del terminal si el terminal no suscribe ningún servicio. A falta de la información de capacidad del terminal más reciente, el contenido del servicio que se proporciona por el servidor al terminal no coincide con las capacidades del terminal y no se puede realizar el servicio con normalidad.
SUMARIO DE LA INVENCIÓN Las formas de realización de la presente invención dan a conocer un método de gestión de terminales en el servicio
denominado Push y un terminal y un servidor que soportan el servicio Push, para garantizar que el servidor pueda realizar sus servicios en conformidad con la más reciente información de capacidad del terminal. El método de gestión de terminales, en el servicio Push, en una forma de realización de la presente invención,
comprende: el envío de una demanda de información de capacidad del terminal a un terminal y la recepción de la información de capacidad del terminal reenviada por el terminal y la gestión de la capacidad del
terminal en función de la información de capacidad del terminal; en donde el envío de la demanda de información de capacidad del terminal comprende: el envío de la demanda de información de capacidad del terminal al terminal si se determina que ninguna información de capacidad del terminal está
memorizada a nivel local o la determinación de que la información de capacidad del terminal, localmente memorizada, está incompleta; la demanda de información de capacidad del terminal transmite la información de capacidad del terminal obtenida, y por
lo tanto:
la información de capacidad del terminal reenviada es la diferencia entre la información de capacidad del terminal actual del terminal y la información de capacidad del terminal transmitida en la demanda y la gestión de las capacidades del terminal en función de la información de capacidad del terminal consiste en: actualizar la información de capacidad del terminal localmente memorizada en función de dicha diferencia. Un método para comunicar la información de capacidad del terminal, en un servicio Push, comprende: la detección, por un terminal, de si su información de capacidad del terminal ha sido modificada en función de una
demanda proporcionada por un servidor y
la comunicación de la información de capacidad del terminal cambiada al servidor una vez que se modifica la información de capacidad del terminal; en donde la demanda transmite la información de capacidad del terminal ya obtenida por el servidor y por lo tanto, el
terminal que recibe la demanda comprueba la diferencia entre la información de capacidad del terminal actual y la
información de capacidad del terminal transmitida en la demanda y comunica la diferencia obtenida al servidor. La solución que antecede, bajo la presente invención, da a conocer que en el servicio Push, el servidor envía una demanda para obtener información de capacidad del terminal desde el terminal o el terminal inicia la actualización de la información de capacidad al servidor, de forma proactiva, después de que se cambie su información de capacidad. Por lo tanto, el servidor puede obtener la información de capacidad del terminal actual a su debido tiempo y puede realizar los servicios en función de la más reciente información de capacidad del terminal.
BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 ilustra un modelo, a modo de ejemplo, de la arquitectura del servicio Push de SIP; La Figura 2 es un diagrama de flujo de un servidor que obtiene la información de capacidad del terminal según la técnica
convencional; La Figura 3 es un diagrama de flujo de la primera forma de realización del método de la presente invención; La Figura 4 es un diagrama de flujo de la segunda forma de realización del método de la presente invención; La Figura 5 es un diagrama de flujo de la tercera forma de realización del método de la presente invención; La Figura 6 representa una estructura de un servidor en la primera forma de realización de la presente invención;
La Figura 7 representa otra estructura de un servidor en la primera forma de realización de la presente invención;
La Figura 8 representa una estructura de un servidor en la segunda forma de realización de la presente invención;
La Figura 9 representa una estructura de un terminal en la primera forma de realización de la presente invención;
La Figura 10 representa otra estructura de un terminal en la primera forma de realización de la presente invención;
La Figura 11 representa otra estructura de un terminal en la primera forma de realización de la presente invención;
La Figura 12 representa una cuarta estructura de un terminal en la primera forma de realización de la presente invención y
La Figura 13 representa una estructura de un terminal en la segunda forma de realización de la presente invención.
DESCRIPCIÓN DETALLADA DE LAS FORMAS DE REALIZACIÓN
Con el fin de conocer mejor la solución técnica, los objetivos y las ventajas de la presente invención, se describe, a continuación, las formas de realización de la presente invención, con más detalle, haciendo referencia a los dibujos adjuntos.
En el servicio Push, el servidor puede enviar una demanda de información de capacidad del terminal al terminal según las exigencias del servicio o el terminal actualiza su información de capacidad al servidor de modo automático o la información de capacidad se actualiza mediante una tercera parte. En el supuesto de que la presente invención se aplique al servicio Push de SIP, se elaboran, a continuación, las formas de realización de la presente invención.
El servicio completo se realiza en un entorno Push de SIP. Por lo tanto, la información de capacidad del terminal se gestiona a través de mensajes SIP. En este caso, el mensaje SIP puede ser un mensaje de opciones Options, mensaje de abono Subscribe o mensaje de notificación Notify.
Si la información de capacidad se gestiona a través de una demanda de consulta desde el servidor, después de recibir la demanda de consulta, el terminal puede decidir si enviar la información de capacidad pertinente en conformidad con la política establecida y seleccionar la información de capacidad del terminal a enviarse en función de la demanda de consulta. Más adelante, el terminal envía su información de capacidad al servidor por intermedio de un mensaje SIP u otro mensaje.
Como alternativa, después que se modifique la información de capacidad, el terminal envía la información de capacidad actualizada al servidor especificado, de forma proactiva, en función de la configuración operativa del servidor. El servidor puede suscribir el evento operativo de actualización de capacidad del terminal y el terminal inicia la acción correspondiente en función de dicho evento operativo.
En las formas de realización de la presente invención, el terminal puede iniciar la actualización de capacidad, de forma proactiva, después de que se modifique su información de capacidad y comunicar la información de capacidad del terminal actualizada al servidor. Más concretamente, la actualización puede ponerse en práctica por intermedio de un mensaje SIP Info o un mensaje de actualización Update. El mensaje transmite la información de capacidad del terminal actualizada en la misma manera que cuando se comunica la información de capacidad del terminal actualizada en las formas de realización siguientes. Puesto que la actualización se inicia por el terminal de forma proactiva, el usuario disfruta de una mejor experiencia.
La presente invención se describe, a continuación, mediante formas de realización detalladas.
En primer lugar, se describen tres formas de realización preferidas para explicar un método de gestión de terminales en un servicio Push de SIP. En las formas de realización preferidas siguientes del método, se supone que la entidad para procesar la información de capacidad del terminal, en el lado del servidor, es un agente emisor Push y la entidad para procesar la información de capacidad del terminal, en el lado del terminal, es un agente receptor Push.
Primera forma de realización
Esta forma de realización da a conocer una solución para la gestión por el servidor de la capacidad del terminal en un entorno Push de SIP. En esta forma de realización, cuando el agente emisor Push necesita realizar un servicio, no se memoriza localmente ninguna información de capacidad del terminal ni la información de capacidad del terminal, localmente memorizada, está incompleta para este servicio. Con el fin de realizar el servicio de forma más adecuada, el agente emisor Push necesita consultar la capacidad del terminal. El agente emisor Push construye una demanda de opciones de SIP y la envía al agente receptor Push por intermedio de una red central de SIP/IP. Después de recibir la demanda de Opciones, el agente receptor Push proporciona una respuesta.
Según se ilustra en la Figura 3, el proceso, en esta forma de realización, comprende las etapas siguientes:
Etapa 1: el agente emisor Push construye y envía una demanda de opciones de SIP a la red central de SIP/IP. La demanda de Opciones de SIP se representa en la tabla 1:
OPTIONS sip:receiver_agent@home.net SIP/2.0 Via: SIP/2.0/UDP sender_agent@home.net;branch=z9hG4bK240f34.1 Max-Forwards: 70 Privacidad: ninguna Desde: <sip:sender_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net> ID llamada: dre36d2v32gnlgiiomm72445 CSeq: 61 OPTIONS Evento: ua-profile Caducidad: 600000 Aceptar: application/ua-profile+xml Contacto: <sip:sender_agent@home.net> Longitud-contenido: 0
Tabla 1
En la tabla 1, el agente emisor Push introduce la dirección del agente receptor en la línea “Para”, esto es, en la dirección de la parte demandada (Request-URI) de SIP e introduce “ua-profile” en la línea “Evento” para indicar la necesidad de consultar la información de capacidad del terminal. Si fuere necesario, el servidor puede añadir la información de capacidad del terminal del usuario en el cuerpo del mensaje y proporcionarlo al terminal o entregar la información de capacidad del terminal obtenida al terminal en un modo de Agente-Usuario. El servidor puede construir un campo de cabecera de consulta de capacidad tal como un campo de cabecera CapReport y poner este campo de cabecera en una demanda de consulta Options para demandar al terminal la comunicación de la información de capacidad.
El formato del informe CapReport puede ser:
CapReport = full / differ /customize / none
Si CapReport = full, el servidor demanda al terminal la comunicación de toda la información de capacidad. Si CapReport = differ, el servidor puede enviar un fichero xml de ua-profile al terminal por intermedio de una demanda Options. El terminal compara su capacidad con el fichero xml, esto es, determina la diferencia entre su información de capacidad y la información de capacidad proporcionada por el servidor y comunica la diferencia al servidor. Si CapReport = customize, el servidor puede dejar espacios en blanco en el fichero xml entregado para que el terminal introduzca contenidos y el terminal rellena los espacios en blanco en el fichero xml y envía el fichero de nuevo al servidor. Si CapReport = none, no se requiere ninguna comunicación de este campo de cabecera.
La extensión del campo de cabecera, antes citada, es solamente un modo de puesta en práctica posible. Para coherencia, utilizamos todavía “even” para marcar la acción de consulta que se va a realizar.
En la tabla 1 anterior, la información de capacidad del terminal se demanda por el servidor a través de "ua-profile". "uaprofile" identifica un modo de identificar y memorizar la información de capacidad del terminal. Actualmente, la información de capacidad del terminal de Push de SIP puede identificarse y memorizarse en otros dos modos. Los tres modos de identificación y memorización se detallan a continuación:
1: Agente Usuario: un agente usuario debe incluir el modelo, versión del software del terminal y preferentemente, incluir el nombre del participante y su versión. El formato de Agente Usuario puede cumplir las “Especificaciones técnicas de terminal móvil WAP 2.0" promulgadas por China Mobile. Cada unidad de datos está delimitada por "/". El fabricante puede añadir propiedades de otros terminales y dichas propiedades se delimitan también por "/". La longitud máxima necesita cumplir las “Especificaciones técnicas de terminal móvil WAP 2.0" promulgadas por China Mobile y la longitud de campo total máxima es de 255 caracteres.
Ejemplo: "nombre fabricante/modelo/versión software terminal/nombre participante y versión (recomendada)”
2. ua-profile: El perfil del Agente Usuario (ua-profile) está diseñado para memorizar parámetros del usuario e información de función de dispositivo. A través del perfil "ua-profile" recibido, el terminal envía la dirección de información de capacidad (URL), memorizada en el servidor de perfiles, al servidor y el servidor consulta la capacidad del terminal en función de la URL proporcionada por el terminal.
3. Cuerpo del mensaje: La información de capacidad del terminal se describe en el cuerpo del mensaje. Un modo opcional es que: la información de capacidad del terminal se describe mediante el lenguaje XML, luego, la información de capacidad se transmite en el cuerpo del mensaje y por último, el cuerpo del mensaje se envía al servidor. A modo de ejemplo, el cuerpo del mensaje puede estar en un formato de Trama de Descripción de Recursos (RDF). La información de capacidad del terminal puede memorizarse en la base de datos en un formato RDF.
Etapa 2: La red central de SIP/IP reenvía el mensaje Options al agente receptor. El formato del mensaje Options reenviado se muestra en la tabla 2:
OPTIONS sip:receiver_agent@home.net SIP/2.0 Via: SIP/2.0/UDP sender_agent@home.net;branch=z9hG4bK240f34.1 Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bKnashds7 Max-Forwards: 70 P-Asserted-Identity: <sip:scscf.home.net> Privacidad: ninguna Desde: <sip:sender_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net> ID llamada: dre36d2v32gnlgiiomm72445 CSeq: 61 OPTIONS Evento: ua-profile Caducidad: 600000 Aceptar: application/ua-profile+xml Contacto: <sip:sender_agent@home.net> Longitud-contenido: 0
Tabla 2
El agente receptor Push está conectado con el agente emisor Push por intermedio de la red central de SIP/IP. Después de recibir el mensaje SIP enviado al agente receptor Push, la red central de SIP/IP puede reenviar la demanda Options de SIP al terminal correspondiente en el formato representado en la tabla 2, en conformidad con las condiciones específicas. Si el usuario tiene múltiples terminales que están todos ellos registrados en el servidor, la red central de SIP/IP puede consultar los terminales de forma concurrente o un modo denominado de horquilla, dependiendo del ajuste operativo en la red central de SIP/IP y luego, informar el resultado de la consulta al servidor.
Etapa 3: El terminal procesa la demanda Options a nivel local.
Después de recibir la demanda Options desde el servidor, el terminal decide el mensaje SIP y determina si permitir la comunicación de la información de capacidad del terminal en función del contenido implicado en el mensaje SIP y la política local del terminal. Si el terminal proporciona la capacidad especificada en la demanda Options y la política local permite la comunicación de dicha información de capacidad, el terminal responde enviando un mensaje 200 OK en la etapa 6. Si el terminal no proporciona la capacidad especificada en la demanda Options o si la política local no permite la comunicación de dicha información de capacidad, el terminal reenvía un mensaje 4xx como información de error en la etapa 4.
La información de capacidad, reenviada por el terminal en respuesta a la demanda Options, puede transmitirse en un campo de cabecera de SIP o un cuerpo de mensaje de SIP. Si la información de capacidad se transmite en un campo de cabecera de SIP, la información de capacidad se transmite en un perfil "ua-profile" o en un modo de Agente-Usuario. Si la información de capacidad se transmite en un cuerpo de mensaje de SIP, la información de capacidad puede enumerarse en el cuerpo del mensaje y de forma opcional, se utiliza un fichero XML para describir las capacidades del terminal y se transmite al servidor por intermedio del cuerpo del mensaje de SIP.
Etapa 4: Si el terminal es incapaz de proporcionar la información de capacidad requerida por el PPG, el terminal reenvía una respuesta 404 Not Found indicativa de no haber sido encontrada.
SIP/2.0 404 Not Found Via: SIP/2.0/UDP receiver_agent@home.com;branch=z9hG4bK240f34.1 P-Asserted-Identity: <sip:scscf.home.net> Privacidad: ninguna Desde: <sip:receiver_agent@home.com>;tag=1928301774
SIP/2.0 404 Not Found Para: < sip:sender_agent@home.com >;tag=31415 ID llamada: dre36d2v32gnlgiiomm72445 CSeq: 61 OPTIONS Contacto: <sip:receiver_agent@home.com> Caducidad: 600000 Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/ua-profile+xml Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 3
En la tecnología de SIP, una respuesta de "4xx" representa un error del cliente. En esta forma de realización, a modo de
5 ejemplo, si una capacidad del terminal requerida por el servidor no está disponible desde el cliente o si la política local no permite la comunicación de dicha información de capacidad, el cliente necesita reenviar la información de error al servidor para terminar la demanda de consulta de capacidad. "404 Not Found" es una forma, a modo de ejemplo, de un mensaje de SIP 4xx. En esta realización, a modo de ejemplo, "404" se utiliza como un código de error en respuesta a la demanda de consulta. En la práctica, otros códigos pueden reenviarse como una respuesta.
10 Etapa 5: Después de recibir la respuesta desde el terminal, la red central de SIP/IP la reenvía al agente emisor Push. El agente emisor Push recibe la respuesta 404 Not Found desde el terminal e interrumpe la consulta sobre las capacidades del terminal.
15 La respuesta 404 Not Found reenviada por la red central de SIP/IP al agente emisor Push se representa en la tabla 4:
SIP/2.0 404 Not Found Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK871y12.1, Via: SIP/2.0/UDP receiver_agent@home.com;branch=z9hG4bK240f34.1 P-Asserted-Identity: <sip:scscf.home.net> Privacidad: ninguna Desde: <sip:receiver_agent@home.com>;tag=1928301774 Para: < sip:sender_agent@home.com >;tag=31415 ID llamada: dre36d2v32gnlgiiomm72445 CSeq: 61 OPTIONS Contacto: <sip:receiver_agent.home.net> Caducidad: 600000 Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/ua-profile+xml Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 4
20 La respuesta "4xx" anterior es una respuesta reenviada cuando el terminal es incapaz de responder a la demanda de consulta Options del servidor de forma correcta.
Etapa 6: El terminal envía una respuesta 200 OK y comunica la información de capacidad demandada por el servidor. El mensaje 200 OK enviado por el terminal, se muestra en la tabla 5: 25
SIP/2.0 200 OK Via: SIP/2.0/UDP receiver_agent@home.com;branch=z9hG4bK240f34.1
SIP/2.0 200 OK P-Asserted-Identity: <sip:scscf.home.net> Privacidad: ninguna Desde: <sip:receiver_agent@home.com>;tag=1928301774 Para: < sip:sender_agent@home.com >;tag=31415 ID llamada: dre36d2v32gnlgiiomm72445 CSeq: 61 OPTIONS Contacto: <sip:receiver_agent.home.net> Caducidad: 600000 Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/ua-profile+xml Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 5
En la tecnología de SIP, la respuesta "2xx" indica un resultado satisfactorio. En esta realización, a modo de ejemplo, si
5 una información de capacidad del terminal, requerida por el servidor, está disponible desde el cliente y la política local permite la comunicación de dicha información de capacidad, el cliente puede reenviar una respuesta de éxito operativo al servidor. La respuesta 200 OK transmite la información de capacidad solicitada.
Etapa 7: El agente emisor Push recibe el mensaje 200 OK que transmite la información de capacidad desde la red
10 central de SIP/IP. El mensaje 200 OK enviado por la red central de SIP/IP al agente emisor Push se representa en la tabla 6:
SIP/2.0 200 OK Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK871y12.1, Via: SIP/2.0/UDP receiver_agent@home.com;branch=z9hG4bK240f34.1 P-Asserted-Identity: <sip:scscf.home.net> Privacidad: ninguna Desde: <sip:receiver_agent@home.com>;tag=1928301774 Para: < sip:sender_agent@home.com >;tag=31415 ID llamada: dre36d2v32gnlgiiomm72445 CSeq: 61 OPTIONS Contacto: <sip:receiver_agent.home.net> Caducidad: 600000 Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/ua-profile+xml Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 6
15 Después de recibir la respuesta desde el terminal, la red central de SIP/IP la reenvía al agente emisor Push. La respuesta "2xx" anterior es una respuesta reenviada cuando el terminal responde a la demanda de consulta Options del servidor, de forma correcta. Si el terminal es incapaz de proporcionar una respuesta correcta, el terminal reenvía un mensaje 4xx.
20 Etapa 8: El PPG, que sirve al agente emisor Push actualiza la información de capacidad del terminal actualmente memorizada.
Después de recibir la respuesta a la demanda Options SIP desde el terminal, el agente emisor Push toma acciones,
dependiendo del tipo de la respuesta. Si la respuesta es información de error tal como 4xx, el agente emisor Push realiza operaciones adicionales según se indica por la información del error. Si la respuesta es un mensaje de éxito operativo tal como 2xx, el PPG, que sirve al agente emisor Push, decide sobre el mensaje recibido, recupera la información de capacidad del terminal y actualiza la información de capacidad actualmente memorizada.
En esta forma de realización, la información de capacidad del terminal, comunicada por el terminal al servidor, cumple los requisitos del servidor de forma explícita y el formato de la información de capacidad del terminal se especifica por el servidor. A modo de ejemplo, si el servidor requiere al terminal que proporcione información de capacidad del terminal en la forma de Agente Usuario, el terminal proporciona la información de capacidad del terminal en la forma de Agente Usuario; si el terminal no tiene ninguna información de capacidad del terminal en la forma de Agente Usuario, la terminal puede proporcionar la información de capacidad del terminal en la forma del perfil ua-profile URL; si el terminal sigue sin tener ninguna información de capacidad del terminal en la forma de ua-profile URL, el terminal puede proporcionar la información de capacidad del terminal en la forma de mensajes. El terminal necesita proporcionar al menos una forma de información de capacidad del terminal. De no ser así, se considera que el terminal es incapaz de proporcionar su información de capacidad y el servidor termina la consulta.
El mensaje Options, implicado en esta forma de realización, es solamente a título de ejemplo. En la práctica, el mensaje Options puede sustituirse con otro mensaje similar.
Segunda forma de realización
En esta forma de realización, después de que el terminal se registre de forma satisfactoria, el servidor envía una demanda Subscribe al terminal. La demanda Subscribe especifica la suscripción al evento operativo de cambio de capacidad del terminal y se proporciona al terminal a través de una red central de SIP/IP. Después de recibir la demanda, el terminal puede utilizar un mensaje Notify para comunicar su información de capacidad al servidor y luego, el servidor memoriza la información de capacidad del terminal que ha recibido. Una vez que se cambien las capacidades del terminal (a modo de ejemplo, se cambia la capacidad de memorización o se cambia la capacidad de aplicación), el terminal puede enviar un mensaje Notify que transmite la información de capacidad modificada al servidor.
Según se ilustra en la Figura 4, en esta forma de realización, según las especificaciones técnicas de Push de SIP, el mensaje de registro enviado en el proceso de registro del terminal no transmite la información de capacidad del terminal. Después de la realización del registro del terminal, el servidor inicia el proceso de gestión de la capacidad del terminal correspondiente. El proceso incluye las etapas siguientes:
Etapa 1: El agente emisor Push suscribe la capacidad del terminal. Más concretamente, el agente emisor Push envía un mensaje Subscribe a la red central de SIP/IP. El mensaje se muestra en la tabla 7:
SUBSCRIBE sip:receiver_agent@home.net SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Ruta: <sip:scscf.home.net:7531 ;lr;comp=sigcomp> Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net> Aceptar-Contacto: *;+g.oma.icsi.push';+ g.oma.iari.push.pushSyncML;;require;explicit Evento: ua-profile; profile-type="application" ID llamada: b89rjhnedlrfjflslj40a222 Requerir: sec-agree Requerir-Proxy: sec-agree CSeq: 101 SUBSCRIBE Evento: ua-profile Caducidad: 600000 Aceptar: application/vnd.syncml.ds.notification Verificar-Seguridad: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Contacto: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp> Longitud-contenido: 0
Tabla 7
El agente emisor Push introduce la dirección del agente receptor Push en el campo de cabecera Request-URI del mensaje Subscribe enviado por la red central de SIP/IP y la dirección especifica el terminal cuya información de
5 capacidad es demandada. El campo Evento describe el contenido suscrito por el mensaje Subscribe. Además, el mensaje Subscribe necesita especificar el modo de reenviar la información de capacidad del terminal y el XML en el campo Aceptar especifica que la información de capacidad del terminal necesita reenviarse por intermedio de mensajes XML.
10 En el campo de cabecera de SIP, el campo de cabecera CapReport puede extenderse en el método descrito en la primera forma de realización para indicar que necesita consultarse la capacidad del terminal y su suscripción.
Etapa 2: La red central de SIP/IP reenvía el mensaje Subscribe al agente receptor Push (terminal). El formato del mensaje Subscribe reenviado se muestra en la tabla 8:
SUBSCRIBE sip:receiver_agent@home.net SIP/2.0 Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net> Aceptar-Contacto: *;+g.oma.icsi.push';+ g.oma.iari.push.PushSyncML;;require;explicit Evento: ua-profile; profile-type="application" ID llamada: b89rjhnedlrfjflslj40a222 Requerir: sec-agree Requerir-Proxy: sec-agree CSeq: 101 SUBSCRIBE Evento: ua-profile Caducidad: 600000 Aceptar: application/vnd.syncml.ds.notification Verificar-Seguridad: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Contacto: <sip: [5555::aaa:bbb:ccc:ddd]: 1357;comp=sigcomp> Longitud-contenido: 0
Tabla 8
El agente receptor Push está conectado con el agente emisor Push a través de la red central de SIP/IP. Después de recibir el mensaje SIP enviado al agente receptor Push, la red central de SIP/IP puede reenviar la demanda SIP
20 Subscribe al agente receptor Push del terminal correspondiente en función de las condiciones específicas. Si el usuario tiene múltiples terminales que están todos ellos registrados en el servidor, la red central de SIP/IP puede suscribir la información de capacidad del terminal de forma concurrente o en un modo denominado de ‘horquilla’, dependiendo del ajuste operativo en la red central de SIP/IP. Si la suscripción tiene éxito operativo, un resultado de la suscripción se reenvía al servidor.
25 Etapa 3: Después de recibir un mensaje Subscribe correctamente, el agente receptor Push reenvía un mensaje 200 OK. El mensaje 200 OK reenviado se muestra en la tabla 9:
SIP/2.0 200 OK Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415
SIP/2.0 200 OK Para: <sip:receiver_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 101 SUBSCRIBE Contacto: <sip:psadm.home.net> Estado-Suscripción: active; Caducidad=600000 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Tipo-Contenido: application/vnd.syncml.ds.notification Longitud-contenido: (...)
[Contenido notificación SyncML DS]
Tabla 9
En la tecnología de SIP, una respuesta "2xx" indica un resultado operativamente satisfactorio. En esta forma de 5 realización, si el cliente recibe el mensaje Subscribe enviado por el servidor y reenviado por la red central de SIP/IP, el cliente puede reenviar una respuesta de éxito operativo al servidor.
Etapa 4: la red central de SIP/IP reenvía el mensaje 200 OK al agente emisor Push. El formato del mensaje 200 OK reenviado se muestra en la tabla 10:
SIP/2.0 200 OK Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:receiver _agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 101 SUBSCRIBE Contacto: <sip:psadm.home.net> Estado-Suscripción: active; Caducidad=600000 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Tipo-Contenido: application/vnd.syncml.ds.notification Longitud-contenido: (...) [Contenido notificación SyncML DS]
Tabla 10
Después de recibir la respuesta desde el terminal, la red central de SIP/IP la reenvía al servidor. La respuesta "2xx" 15 anterior es una respuesta reenviada cuando el terminal responde a la demanda de consulta Subscribe del servidor, de forma correcta.
Etapa 5: Después de recibir la demanda Subscribe desde el servidor, el terminal resuelve sobre el mensaje de SIP y
realiza una determinación en conformidad con la política local del terminal. Si el terminal puede proporcionar su propia información de capacidad y la política local permite la comunicación de la información de capacidad, el terminal reenvía un mensaje 2xx indicando el éxito operativo de la suscripción y envía un mensaje de notificación Notify que transmite la información de capacidad del terminal en la etapa 8. Más adelante, el terminal comprueba si se modifica su capacidad.
5 Una vez que se modifique su capacidad, el terminal envía un mensaje de notificación Notify que transmite la información de capacidad modificada al servidor; si la política local del terminal no permite la comunicación de la información de capacidad, el terminal reenvía un mensaje 4xx como información de error en la etapa 6.
La información de capacidad reenviada por el terminal en respuesta a la demanda Subscribe puede transmitirse en un
10 campo de cabecera de SIP o un cuerpo del mensaje SIP. Si la información de capacidad se transmite un campo de cabecera de SIP, la información de capacidad se transmite en un perfil ua-profile o modo de Agente-Usuario. Si la información de capacidad se transmite en un cuerpo del mensaje SIP, la información de capacidad puede citarse en el cuerpo del mensaje y de forma opcional, se utiliza un fichero XML para describir la capacidad del terminal y se transmite al servidor por intermedio del cuerpo del mensaje SIP.
15 Etapa 6: Cuando falla la suscripción o el terminal es incapaz de proporcionar su información de capacidad, el terminal envía un mensaje 404 Not Found al servidor, en donde el servidor decide si suscribirse de nuevo en conformidad con la política establecida. El mensaje 404 Not Found se muestra en la tabla 11:
SIP/2.0 404 Not Found Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 101 SUBSCRIBE Contacto: <sip:psadm.home.net> Estado-Suscripción: inactive; Caducidad=0 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 11
En la tecnología de SIP, una respuesta "4xx" representa un error del cliente. En esta realización, a modo de ejemplo, si el cliente es incapaz de proporcionar su información de capacidad o incapaz de dar respuesta al mensaje Subscribe o si la
25 política local no permite la comunicación de dicha información de capacidad, el cliente necesita reenviar la información de error al servidor para terminar la demanda de suscripción de capacidad. El mensaje "404 Not Found" es una realización, a modo de ejemplo, de un mensaje de SIP 4xx. En esta realización, a modo de ejemplo, "404" se utiliza como un código de error en respuesta a la demanda de consulta. En la práctica, otros códigos pueden reenviarse como una respuesta.
30 Etapa 7: La red central de SIP/IP reenvía el mensaje 404 Not Found indicativo de fallo de la suscripción al servidor. El mensaje 404 Not Found se muestra a continuación:
SIP/2.0 404 Not Found Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna SIP/2.0 404 Not Found Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 101 SUBSCRIBE Contacto: <sip:psadm.home.net> Estado-Suscripción: inactive; Caducidad=0 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 12
Después de recibir la respuesta desde el terminal, la red central de SIP/IP la reenvía al servidor. La respuesta "4xx" 5 anterior es una respuesta reenviada cuando el terminal es incapaz de dar respuesta a la demanda Subscribe del servidor, de forma correcta.
Etapa 8: El terminal envía un mensaje de notificación Notify que transmite la información de capacidad modificada a la red central de SIP/IP. El mensaje Notify se muestra en la tabla 13:
NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> Ruta: <sip:scscf.home.net;lr> Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 112 NOTIFY Estado-Suscripción: active; Caducidad=600000 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Tipo-Contenido: application/vnd.syncml.ds.notification Contacto: <sip:psadm.home.net> Longitud-contenido: (...)
[Contenido notificación SyncML DS]
Tabla 13
El terminal puede comunicar la información de capacidad al servidor por intermedio de un mensaje Notify
15 inmediatamente después de registrarse o comunicar la información de capacidad después de que se cambie la información de capacidad del terminal. El campo Evento en el mensaje Notify indica que la respuesta es un paquete de eventos de perfil ua-profile y el Tipo-Contenido es el tipo de contenido especificado en el mensaje Subscribe.
Etapa 9: La red central de SIP/IP reenvía el mensaje Notify al servidor. El formato del mensaje Notify reenviado se muestra en la tabla 14:
NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 112 NOTIFY Estado-Suscripción: active; Caducidad=600000 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Tipo-Contenido: application/vnd.syncml.ds.notification Contacto: <sip:psadm.home.net> Longitud-contenido: (...)
[Contenido notificación SyncML DS]
5 Tabla 14
Después de recibir el mensaje Notify desde el terminal, la red central de SIP/IP lo reenvía al servidor. En la realización anterior, a modo de ejemplo, habida cuenta de que el tipo de contenido de la suscripción es XML, la información de capacidad del terminal se describe en XML. Sin embargo, la información de capacidad puede describirse en otras formas
10 tales como ua-profile URL y Agente Usuario. El formato XML se proporciona aquí a modo de ejemplo, pero es el mismo con otros formatos de la información de capacidad comunicada.
Etapa 10: El servidor actualiza la información de capacidad de terminal actualmente memorizada.
15 En esta etapa, después de recibir la información de capacidad desde el terminal, el servidor determina si se envía la información de capacidad inmediatamente después de que se registre el terminal. Si la información de capacidad se envía inmediatamente después de que se registre el terminal, puesto que la información de capacidad no está memorizada en el servidor con anterioridad, el servidor memoriza la información de capacidad del terminal actual y luego, realiza las operaciones Push de SIP, tales como enviar los contenidos de servicios en función de la información de
20 capacidad del terminal proporcionada por el propio terminal. Si el servidor ha memorizado la información de capacidad del terminal antes de recibir la respuesta Notify, puesto que el mensaje Notify transmite la información que existe después del cambio de la información de capacidad del terminal, el servidor actualiza la información de capacidad del terminal memorizada.
25 Etapa 11: El servidor envía un mensaje Notify 200 OK al terminal. El mensaje 200 OK se muestra en la tabla 15:
SIP/2.0 200 OK Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net>;tag=151170
SIP/2.0 200 OK ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 112 NOTIFY Contacto: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp> Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 15
En la tecnología de SIP, una respuesta "2xx" indica un resultado de éxito operativo. En esta realización, a modo de 5 ejemplo, si el servidor recibe correctamente el mensaje Notify reenviado por la red central de SIP/IP, el servidor puede reenviar una respuesta de éxito operativo al terminal.
Etapa 12: La red central de SIP/IP reenvía la respuesta 200 OK al terminal. El mensaje 200 OK se muestra en la tabla
16: 10
SIP/2.0 200 OK Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 P-Asserted-Identity: <sip:scscf.home.net> Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 112 NOTIFY Contacto: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp> Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 16
Después de recibir la respuesta desde el servidor, la red central de SIP/IP la reenvía al terminal. La respuesta "2xx" 15 anterior es una respuesta reenviada cuando el servidor da respuesta al mensaje Notify del terminal, de forma correcta.
Una vez que se modifique su capacidad, el terminal comunica la información de capacidad modificada al servidor. La información de capacidad puede comunicarse en la forma de Agente Usuario o en ua-profile u otras formas de memorización de la información de capacidad en el terminal. Dichas formas de comunicación de la información de
20 capacidad son susceptibles de conocimiento para el servidor. El mensaje Subscribe/Notify anteriormente proporcionado es tan solo a modo de ejemplo. Es el mismo con otros mensajes mediante los que se comunica la información de capacidad.
Tercera forma de realización
25 En esta forma de realización, el servidor puede utilizar una tercera parte para gestionar la capacidad del terminal. A modo de ejemplo, el si el terminal es incapaz de comunicar el cambio de capacidad al servidor después de que se cambie la capacidad del terminal o si el servidor es incapaz de obtener la información de capacidad del terminal modificada, se puede utilizar una tercera parte para comunicar información de capacidad del terminal a la red central de SIP/IP y luego,
30 la red central de SIP/IP envía la información de capacidad al servidor. De esta forma, el servidor gestiona la capacidad del terminal.
En esta forma de realización, se supone que el agente Push 1 y el agente Push 2 son terminales registrados en la red central de SIP/IP y pertenecen al mismo Public URI y son terminales diferentes de un solo usuario. En este caso, un
5 terminal capaz de acceder a la red central de SIP/IP y de memorizar la información de capacidad de otros terminales del usuario se puede seleccionar en conformidad con una política y este terminal comunica la información de capacidad de otros terminales al servidor. A modo de ejemplo, el agente receptor Push 1 sirve como terminal tercero que comunica la información de capacidad del agente receptor Push 2 al servidor. Se supone que:
10 La dirección del Contacto del agente receptor Push 1 es: [6666::aaa:bbb:ccc:ddd]: 1357;
La dirección del Contacto del agente receptor Push 2 es: [7777::aaa:bbb:ccc:ddd]:1357 y
La dirección del Contacto del agente emisor Push es: sip:[5555::aaa:bbb:ccc:ddd]:1357.
15 Según se ilustra en la Figura 5, el proceso, en esta forma de realización, comprende las etapas siguientes:
Etapa 1: El agente emisor Push efectúa la suscripción para las capacidades del agente receptor Push 2. En primer lugar, el agente emisor Push envía un mensaje Subscribe a la red central de SIP/IP. El mensaje Subscribe se muestra en la
20 tabla 17:
SUBSCRIBE sip:receiver_agent@home.net SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Ruta: <sip:scscf.home.net:7531 ;lr;comp=sigcomp> Ruta: <sip:[6666::aaa:bbb:ccc:ddd]: 1357;lr;comp=sigcomp> Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:sender_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net> Aceptar-Contacto: *;+g.oma.icsi.push';+ g.oma.iari.push.PushSyncML;;require;explicit Evento: ua-profile;profile-type="application" ID llamada: b89rjhnedlrfjflslj40a222 Requerir: sec-agree Requerir-Proxy: sec-agree CSeq: 101 SUBSCRIBE Caducidad: 600000 Aceptar: application/vnd.syncml.ds.notification+xml Verificar-Seguridad: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Contacto: <sip: [5555::aaa:bbb:ccc:ddd]: 1357;comp=sigcomp> Longitud-contenido: 0
Tabla 17
25 Según se muestra en la tabla anterior, la dirección del agente receptor Push 2 se introduce en el campo de cabecera Request-URI del mensaje Subscribe para indicar el terminal cuya información de capacidad se consulta. El campo Evento indica que el contenido suscrito es la información de capacidad del terminal y especifica que la información de capacidad del terminal necesita reenviarse en la forma de ua-profile.
30 En el campo de cabecera de SIP, el campo de cabecera CapReport puede extenderse en el método descrito en la primera forma de realización para indicar que las capacidades del terminal necesitan consultarse y suscribirse.
Etapa 2: La red central de SIP/IP reenvía el mensaje Subscribe al agente receptor Push 2 (terminal 2). El mensaje Subscribe se muestra en la tabla 18:
SUBSCRIBE sip:[6666::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcompSIP/2.0 Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1
SUBSCRIBE sip:[6666::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcompSIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:sender_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net> Aceptar-Contacto: *;+g.oma.icsi.push';+ g.oma.iari.push.PushSyncML;;require;explicit Evento: ua-profile;profile-type="application" ID llamada: b89rjhnedlrfjflslj40a222 Requerir: sec-agree Requerir-Proxy: sec-agree CSeq: 101 SUBSCRIBE Caducidad: 600000 Aceptar: application/vnd.syncml.ds.notification Verificar-Seguridad: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Contacto: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp> Longitud-contenido: 0
Tabla 18
En esta etapa, el agente receptor Push 2 está conectado con el agente emisor Push por intermedio de la red central de 5 SIP/IP. Después de recibir el mensaje de SIP enviado al agente receptor Push 2, la red central de SIP/IP puede reenviar la demanda SIP Subscribe al terminal correspondiente en función de las condiciones específicas.
Etapa 3: El agente emisor Push efectúa la suscripción de la información de capacidad desde el terminal de nuevo, a modo de ejemplo, a través de un mensaje de abono Subscribe. El mensaje Subscribe se muestra en la tabla 19.
SUBSCRIBE sip:receiver_agent@home.net SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Ruta: <sip:scscf.home.net:7531 ;lr;comp=sigcomp> Ruta: <sip: [7777::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcomp> Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:sender_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net> Aceptar-Contacto: *;+g.oma.icsi.push';+ g.oma.iari.push.PushSyncML;;require;explicit Evento: ua-profile;profile-type="application" ID llamada: b89rjhnedlrfjflslj40a222 Requerir: sec-agree Requerir-Proxy: sec-agree CSeq: 101 SUBSCRIBE Caducidad: 600000 Aceptar: application/vnd.syncml.ds.notification Verificar-Seguridad: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Contacto: <sip:[5555::aaa:bbb:ccc:ddd]: 1357;comp=sigcomp> Longitud-contenido: 0
Tabla 19
Antes de esta etapa, el agente emisor Push deja de recibir la respuesta al mensaje Subscribe correctamente debido al 17
transcurso del tiempo de espera. Por lo tanto, el agente emisor Push efectúa la suscripción de la información de capacidad del terminal 2 de nuevo en conformidad de la política y envía el mensaje de abono Subscribe al terminal 1 preferido por el usuario registrado.
Etapa 4: La red central de SIP/IP reenvía el mensaje Subscribe al agente receptor Push 1 (terminal 1). El mensaje Subscribe se muestra en la tabla 20:
SUBSCRIBE sip:[7777::aaa:bbb:ccc:ddd):1357;lr;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:sender_agent@home.net>;tag=31415 Para: <sip:receiver_agent@home.net> Aceptar-Contacto: *;+g.oma.icsi.push';+ g.oma.iari.push.PushSyncML;;require;explicit Evento: ua-profile;profile-type="application" ID llamada: b89rjhnedlrfjflslj40a222 Requerir: sec-agree Requerir-Proxy: sec-agree CSeq: 101 SUBSCRIBE Caducidad: 600000 Aceptar: application/vnd.syncml.ds.notification Verificar-Seguridad: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Contacto: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp> Longitud-contenido: 0
Tabla 20
10 El agente receptor Push 1 está conectado con el agente emisor Push por intermedio de la red central de SIP/IP. Después de recibir el mensaje de SIP, enviado al agente receptor Push 1, la red central de SIP/IP puede reenviar la demanda de abono SIP Subscribe al terminal correspondiente (esto es, terminal 1) en función de las condiciones específicas.
15 Etapa 5: El agente receptor Push 1 es un terminal preferido por el usuario y memoriza la información de capacidad de otros terminales del usuario. Cuando la red central de SIP/IP envía un mensaje Subscribe al terminal 1 para la suscripción de la información de capacidad del terminal 2, el agente receptor Push 1 puede consultar la información de capacidad memorizada de otros terminales y determinar si está memorizada la información de capacidad del agente receptor Push 2. Si el terminal 1 memoriza la información de capacidad del terminal requerida por el servidor y está
20 permitido el envío de la información al servidor, el terminal 1 reenvía un mensaje 2xx que indica el éxito operativo de la suscripción y envía un mensaje Notify que transmite la información de capacidad memorizada del terminal 2 al servidor. La información de capacidad comunicada se memoriza en la misma forma que la información de capacidad del terminal
2. Si el terminal 1 no encuentra ninguna información de capacidad del terminal requerida por el servidor o si la política local del terminal 1 no permite la comunicación de la información de capacidad del terminal requerida por el servidor, el
25 terminal 1 reenvía un mensaje 4xx que indica el fallo de la suscripción. En esta realización, a modo de ejemplo, si la suscripción tiene éxito operativo, el proceso prosigue con la etapa 8; de no ser así, el proceso prosigue con la etapa 6.
Etapa 6: El agente receptor Push 1 envía un mensaje 404 Not Found al servidor. El mensaje 404 Not Found se muestra en la tabla 21:
SIP/2.0 404 Not Found Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna SIP/2.0 404 Not Found Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:sender_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 101 SUBSCRIBE Contacto: <sip:[6666::aaa:bbb:ccc:ddd]:357;lr;comp=sigcomp > Estado-Suscripción: inactive; Caducidad=0 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 21
En la tecnología de SIP, una respuesta "4xx" representa un error del cliente. En esta realización, a modo de ejemplo, si el
5 terminal 1 es incapaz de encontrar la información de capacidad del terminal requerida por el servidor o es incapaz de respuesta al mensaje Subscribe o si la política local no permite la comunicación de dicha información de capacidad, el terminal 1 necesita reenviar información de error al servidor para terminar la demanda de suscripción de capacidad. La respuesta "404 Not Found" es a modo de ejemplo de un mensaje de SIP 4xx. En esta forma de realización, a modo de ejemplo, "404" se utiliza como un código de error en respuesta a la demanda de consulta. En la práctica, otros códigos
10 pueden reenviarse como una respuesta.
Etapa 7: La red central de SIP/IP reenvía la información de error enviada por el terminal 1 al servidor. El mensaje 404 Not Found reenviado se muestra en la tabla 22:
SIP/2.0 404 Not Found Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:sender_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222' CSeq: 101 SUBSCRIBE Contacto: <sip: [6666::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcomp > Estado-Suscripción: inactive; Caducidad=0 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Longitud-contenido: 0
Tabla 22
Después de recibir la respuesta desde el terminal, la red central de SIP/IP reenvía el mensaje 404 Not Found al servidor. El mensaje 4xx anterior es una respuesta a la demanda de suscripción Subscribe del servidor en el caso de que el 20 terminal sea incapaz de encontrar la información de capacidad del terminal requerida por el servidor o la política local no permita la comunicación de dicha información de capacidad.
Etapa 8: El terminal 1 recibe el mensaje Subscribe desde el servidor de forma correcta y encuentra la información de
capacidad del terminal requerida por el servidor y reenvía un mensaje 200 OK. El mensaje 200 OK se muestra en la tabla
23.
SIP/2.0 200 OK Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:sender_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 101 SUBSCRIBE Contacto: <sip: [6666::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcomp > Estado-Suscripción: active; Caducidad=600000 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Tipo-Contenido: application/vnd.syncml.ds.notification Longitud-contenido: (...)
[Contenido notificación SyncML DS]
5 Tabla 23
En la tecnología de SIP, una respuesta "2xx" indica un resultado de éxito operativo. En esta realización, a modo de ejemplo, si el cliente recibe correctamente el mensaje Subscribe enviado por el servidor y reenviado por la red central de SIP/IP y encuentra la información de capacidad requerida por el servidor, el cliente puede reenviar una respuesta de
10 éxito operativo al servidor.
Etapa 9: La red central de SIP/IP reenvía el mensaje 200 OK al servidor. El mensaje 200 OK se muestra en la tabla 24:
SIP/2.0 200 OK Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11 Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:sender_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 101 SUBSCRIBE Contacto: <sip: [6666::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcomp > Estado-Suscripción: active; Caducidad=600000 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en SIP/2.0 200 OK Soportado: foo Tipo-Contenido: application/vnd.syncml.ds.notification Longitud-contenido: (...)
[Contenido notificación SyncML DS]
Tabla 24
Después de la recepción de la respuesta desde el terminal, la red central de SIP/IP reenvía el mensaje 200 OK al 5 servidor. El “2xx” anterior es una respuesta reenviada cuando el terminal responde correctamente a la demanda de consulta de abono Subscribe del servidor.
Etapa 10: El terminal 1 envía un mensaje Notify que transmite la información de capacidad del terminal encontrada a la red central de SIP/IP. El mensaje Notify se muestra en la tabla 25:
NOTIFY sip:[6666::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP scscf.home.net;branch=z9hG4bK351g45.1 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:sender_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 112 NOTIFY Estado-Suscripción: active; Caducidad=600000 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Tipo-Contenido: application/vnd.syncml.ds.notification Contacto: <sip: [6666::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcomp> Longitud-contenido: (...)
[Contenido notificación SyncML DS]
Tabla 25
En esta etapa, el terminal 1 puede enviar un mensaje Notify que transmite la información de capacidad del terminal
15 requerida al servidor después de encontrar la información de capacidad del terminal requerida por el servidor. El campo Evento en el mensaje Notify indica que la respuesta es un paquete de eventos operativos de ua-profile y el tipo-contenido es el tipo de contenido especificado en el mensaje Subscribe. En este proceso, el terminal 1 puede comunicarse su propia información de capacidad o la información de capacidad de otros agentes. Las capacidades de terminales pueden indicarse por un campo de cabecera extendido o describirse mediante la información pertinente en un fichero XML.
20 Si las capacidades del terminal se indican por un campo de cabecera extendida, el campo de cabecera CapReportFrom puede extenderse para indicar las capacidades del terminal. A modo de ejemplo, si la información de capacidad anterior procede del terminal 1 y el terminal 1 informa la información de capacidad a través de un mensaje Notify, este campo de cabecera es susceptible de ignorarse.
25 Si el terminal 1 comunica la información de capacidad a través de un mensaje Notify, pero la información de capacidad comunicada es la información de capacidad del terminal 2, el campo de cabecera necesita expresarse como: CapReportFrom: <sip: [7777::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcomp>.
Si el terminal 1 comunica la información de capacidad del terminal 1 y del terminal 2 a través de un mensaje Notify, el campo de cabecera necesita expresarse como:
5 CapReportFrom: <sip: [7777::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcomp>; <sip: [6666::aaa:bbb:ccc:ddd]:1357;lr;comp=sigcomp>.
Etapa 11: La red central de SIP/IP reenvía el mensaje Notify al servidor. El formato del mensaje Notify reenviado se 10 muestra en la tabla 26:
NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 69 Identidad-Preferida-P: "John Doe" <sip:receiver_agent@home.net> Privacidad: ninguna Desde: <sip:receiver_agent@home.net>;tag=31415 Para: <sip:sender_agent@home.net>;tag=151170 ID llamada: b89rjhnedlrfjflslj40a222 CSeq: 112 NOTIFY Estado-Suscripción: active; Caducidad=600000 Evento: ua-profile Permitir: INVITE, ACK, CANCEL, OPTIONS, BYE Aceptar: application/vnd.syncml.ds.notification Aceptar-Codificación: gzip Aceptar-Lenguaje: en Soportado: foo Tipo-Contenido: application/vnd.syncml.ds.notification Contacto: <sip:psadm.home.net> Longitud-contenido: (...)
[Contenido notificación SyncML DS]
Tabla 26
15 En esta etapa, después de recibir el mensaje Notify desde el terminal, la red central de SIP/IP lo reenvía al servidor. En el ejemplo anterior, puesto que el terminal 1 memoriza la información de capacidad del terminal 2 en la forma de XML, la información de capacidad del terminal 2 se describe en XML. Sin embargo, la información de capacidad puede describirse en otras formas tales como ua-profile URL y Agente Usuario. Aunque el formato XML se proporcione aquí a modo de ejemplo, es el mismo con otros formatos de la información de capacidad comunicada.
20 Etapa 12: El servidor actualiza la información de capacidad del terminal memorizada.
En esta etapa, el servidor recibe la información de capacidad del terminal enviada por el terminal 1. El servidor puede encontrar la información de capacidad del terminal requerida en el mensaje Notify. Puesto que el servidor efectúa la
25 suscripción del información de capacidad del terminal a través de un mensaje de abono Subscribe, el servidor no estima que el mensaje Notify enviado desde el terminal 1 transmite la información de capacidad del terminal 1, pero considera que la respuesta al mensaje Subscribe transmite la información de capacidad requerida por el servidor.
Después de obtener la información de capacidad del terminal, el servidor realiza un proceso Push de SIP normal y lleva a 30 la información de contenido del servicio a iniciarse por el servidor para el terminal 2.
En esta forma de realización, a modo de ejemplo, la demanda enviada por el servidor al terminal 1 necesita solamente especificar el terminal cuya información de capacidad está siendo consultada, pero no se necesita especificar la forma de reenvío de la información de capacidad. La información de capacidad del terminal comunicada se memoriza en una
35 tercera parte en la forma de Agente Usuario o ua-profile o en cuerpo del mensaje en un formato XML.
En esta forma de realización, el terminal preferido por el usuario puede necesitar autenticarse y autorizarse cuando este
terminal obtiene la información de capacidad de otros terminales del usuario; las operaciones de memorización y comunicación por la tercera parte de la información de capacidad de otros terminales puede ocurrir entre terminales de diferentes usuarios y, en este caso, las funciones de autenticación y autorización son obligatorias.
El mensaje Subscribe/Notify anteriormente proporcionado es solamente a modo de ejemplo. Es el mismo con otros mensajes a través de los que se comunica la información de capacidad.
La Figura 6 representa un servidor que soporta un servicio Push de SIP en la primera forma de realización de la presente invención. El servidor 60 incluye:
un módulo de envío 61, adaptado para enviar una demanda de información de capacidad del terminal a un terminal;
un módulo de recepción 62, adaptado para recibir la información de capacidad del terminal reenviada por el terminal en función de la demanda y
un módulo de gestión de terminal 63, adaptado para gestionar las capacidades del terminal en función de la información de capacidad del terminal recibida.
La Figura 7 representa un servidor que soporta un servicio Push de SIP en la segunda forma de realización de la presente invención. El servidor 70 incluye:
un módulo de generación de demandas de capacidad 74, adaptado para generar una demanda de información de capacidad del terminal a enviarse al terminal después de la determinación de que el servidor no memoriza la información de capacidad del terminal o la información de capacidad del terminal, memorizada en el servidor, es incompleta;
un módulo de envío 71, adaptado para enviar la demanda de información de capacidad del terminal al terminal;
un módulo de recepción 72, adaptado para recibir la información de capacidad del terminal reenviada por el terminal en función de la demanda y
un módulo de gestión de terminal 73, adaptado para gestionar las capacidades del terminal en función de la información de capacidad del terminal recibida.
En las dos formas de realización de servidores anteriores, si la información de capacidad del terminal, procedente del módulo de recepción, está en la forma de Agente Usuario o un cuerpo del mensaje, y el servidor no memoriza la información de capacidad del terminal correspondiente, el módulo de gestión del terminal memoriza directamente la información de capacidad del terminal; si el servidor memoriza ya la información de capacidad del terminal correspondiente, el módulo de gestión del terminal actualiza la información de capacidad del terminal memorizada.
Además, la información de capacidad del terminal, procedente del módulo de recepción, puede estar en la forma de uaprofile. En este caso, el módulo de gestión del terminal necesita interaccionar con un servidor de perfiles para obtener la información de capacidad del terminal específica.
La Figura 8 representa un servidor que soporta un servicio Push de SIP en la tercera forma de realización de la presente invención. El servidor comprende:
un módulo de recepción 81, adaptado para recibir información de capacidad, comunicada por el terminal y para enviar la información de capacidad del terminal recibida a un módulo de gestión del terminal y
un módulo de gestión de 82, adaptado para actualizar la información de capacidad del terminal memorizada en función de la información de capacidad del terminal desde el módulo de recepción.
En esta forma de realización, si la información de capacidad comunicada por el terminal está en la forma de Agente Usuario o un cuerpo del mensaje, el módulo de gestión del terminal utiliza la información de capacidad comunicada para actualizar directamente la información de capacidad del terminal.
Si la información de capacidad del terminal, comunica por el terminal, está en la forma de ua-profile, el módulo de gestión del terminal necesita interaccionar con el servidor de perfiles para obtener la información de capacidad del terminal específica.
En las tres formas de realización del servidor anteriores, el servidor puede ser agente emisor Push.
La Figura 9 representa un terminal que soporta un servicio Push de SIP en la primera forma de realización de la presente invención. El terminal comprende:
un módulo de recepción 91, adaptado para recibir una demanda de información de capacidad del terminal desde un
servidor y para transmitir la demanda a un módulo de comunicación de información de capacidad del terminal;
un módulo de procesamiento de capacidad del terminal 93, adaptado para: obtener información de capacidad del terminal en función de la demanda de información de capacidad del terminal recibida y para transmitir la información de capacidad del terminal obtenida al módulo de envío y
un módulo de envío 92, adaptado para: recibir la información de capacidad del terminal desde el módulo de comunicación de información de capacidad del terminal y para enviar la información de capacidad del terminal al servidor.
Después de recibir la demanda de información de capacidad del terminal, el módulo de procesamiento de capacidad del terminal puede obtener directamente la información de capacidad del terminal y transmitirla al módulo de envío o realizar una determinación y decidir si obtener, o no, la información de capacidad del terminal correspondiente y transmitirla al módulo de envío.
En este último caso, según se ilustra en la Figura 10, el módulo de procesamiento de capacidad del terminal 93 puede incluir:
un módulo de consulta 931, adaptado para recibir una demanda de información de capacidad del terminal desde un módulo de recepción, para comprobar si la información de capacidad del terminal correspondiente está memorizada localmente en función de la demanda y para transmitir la información de capacidad del terminal encontrada a un módulo de comunicación de información de capacidad del terminal o notificar a un módulo de comunicación de información de error que no se encuentra ninguna información de capacidad del terminal correspondiente;
un módulo de comunicación de información de capacidad del terminal 932, adaptado para transmitir la información de capacidad del terminal recibida al módulo de envío y
un módulo de comunicación de información de error 933, adaptado para: generar una respuesta de error en función de la notificación y para transmitir la respuesta de error al módulo de envío.
En consecuencia, el módulo de envío reenvía la respuesta de error desde el módulo de comunicación de información de error al servidor.
En esta forma de realización, el terminal puede comunicar la información de capacidad actualizada al servidor una vez que se cambia la capacidad del terminal. En este caso, según se ilustra en la Figura 11, el terminal comprende, además, un módulo de control de actualización de capacidad 111, que está adaptado para: supervisar si se cambia la información de capacidad y notificarlo al módulo de procesamiento de capacidad del terminal una vez que se cambie la información de capacidad. En este caso, el módulo de procesamiento de capacidad del terminal obtiene la información de capacidad del terminal actual en función de la notificación y la transmite al módulo de envío.
En esta forma de realización, la información de capacidad del terminal demandada es la información de capacidad de este terminal.
Si la información de capacidad del terminal demandada es la información de capacidad de otro terminal, según se ilustra en la Figura 12, el terminal incluye, además, un módulo 121 para memorizar la información de capacidad de otros terminales, que está adaptado para memorizar la información de capacidad de otros terminales. En este caso, el módulo de procesamiento de la capacidad del terminal está adaptado, además, para: obtener la información de capacidad del terminal desde el módulo para memorizar la información de capacidad de otros terminales en función de la demanda de información de capacidad del terminal recibida y para transmitir la información de capacidad del terminal obtenida al módulo de envío.
La Figura 13 representa un terminal que soporta un servicio Push de SIP en la segunda forma de realización de la presente invención. El terminal comprende:
un módulo de procesamiento de capacidad del terminal 131, adaptado para transmitir información modificada de capacidad del terminal al módulo de envío una vez que se modifique la información de capacidad del terminal y
un módulo de envío 132, adaptado para: recibir la información de capacidad del terminal desde el módulo de procesamiento de capacidad del terminal y para enviar la información de capacidad del terminal al servidor.
En las dos formas de realización del terminal anteriores, el terminal puede ser un agente receptor Push.
Las formas de realización anteriormente descritas son formas de realización preferidas de la presente invención. En la práctica, los expertos en esta materia pueden realizar modificaciones al método dado a conocer por la presente invención con el fin de satisfacer las exigencias operativas específicas. Aunque la invención se ha descrito a través de algunas formas de realización, a modo de ejemplo, la invención no está limitada a dichas formas de realización.

Claims (14)

  1. REIVINDICACIONES
    1. Un método de gestión de terminal en un servicio de tipo Push, que comprende:
    enviar una demanda de información de capacidad del terminal a un terminal y
    recibir información de capacidad del terminal reenviada por el terminal y gestionar las capacidades del terminal según la información de capacidad del terminal;
    en donde la etapa de enviar la demanda de información de capacidad del terminal comprende: enviar la demanda de información de capacidad del terminal al terminal si se determina que ninguna información de capacidad del terminal del terminal está memorizada localmente o si se determina que la información de capacidad del terminal memorizada localmente está incompleta y
    en donde dicha demanda de información de capacidad del terminal transmite la información de capacidad del terminal obtenida y
    en donde dicha información de capacidad del terminal reenviada es una diferencia entre la información de capacidad del terminal actual del terminal y la información de capacidad del terminal transmitida en la demanda y
    en donde la etapa que consiste en gestionar las capacidades del terminal según la información de capacidad del terminal comprende, además, actualizar la información de capacidad del terminal memorizada localmente en función de la diferencia.
  2. 2.
    El método de gestión de terminal en un servicio de tipo Push según la reivindicación 1, en donde:
    la demanda de información de capacidad del terminal se transmite en un mensaje de opciones de Protocolo de Iniciación de Sesión, SIP, y por lo tanto, la información de capacidad del terminal reenviada se transmite en un mensaje 200 OK.
  3. 3.
    El método de gestión de terminal en un servicio de tipo Push según la reivindicación 1, en donde:
    la demanda de información de capacidad del terminal se envía por intermedio de un mensaje de abono Subscribe de Protocolo de Iniciación de Sesión, SIP, y por lo tanto, la información de capacidad del terminal reenviada se transmite en un mensaje Notify de SIP.
  4. 4.
    El método de gestión de terminal en un servicio de tipo Push según la reivindicación 1, en donde, después del envío de la demanda de información de capacidad del terminal al terminal, el método comprende, además, las etapas siguientes:
    si ninguna respuesta se recibe del terminal en un tiempo preestablecido, enviar la demanda de información de capacidad del terminal a una tercera parte que memoriza la información de capacidad del terminal para demandar la información de capacidad del terminal, recibir la información de capacidad del terminal reenviada por la tercera parte y gestionar el terminal según la información de capacidad del terminal.
  5. 5.
    El método de gestión de terminal en un servicio de tipo Push, según la reivindicación 4, en donde:
    la demanda de información de capacidad del terminal, enviada a la tercera parte, se transmite en un mensaje Options del Protocolo de Iniciación de Sesión, SIP, y por lo tanto, la información de capacidad del terminal reenviada por la tercera parte se transmite en un mensaje 200 OK o
    la demanda de información de capacidad del terminal, enviada a la tercera parte, se transmite en un mensaje de abono Subscribe SIP y por lo tanto, la información de capacidad del terminal reenviada por la tercera parte se transmite en un mensaje Notify de SIP.
  6. 6.
    El método de gestión de terminal en un servicio de tipo Push, según la reivindicación 2, la reivindicación 3 o la reivindicación 5, en donde:
    la demanda de información de capacidad del terminal se establece en un elemento de evento operativo del mensaje de opciones SIP o del mensaje de abono SIP Subscribe o se establece en un campo de cabecera de demanda de capacidad añadido en el mensaje de opciones SIP o en el mensaje de abono SIP Subscribe.
  7. 7.
    El método de gestión de terminal en un servicio de tipo Push, según la reivindicación 6, en donde:
    los valores del campo de cabecera comprenden: full, differ, customize y none y
    si el valor del campo de cabecera es “full”, la demanda requiere al terminal comunicar todas las informaciones de
    capacidad; si el valor del campo de cabecera es “differ”, la demanda requiere al terminal verificar la diferencia entre la información de capacidad del terminal memorizada localmente y la información de capacidad del terminal memorizada en un servidor de red y comunicar la diferencia; si el valor del campo de cabecera es “customize” la demanda requiere al terminal introducir la información de capacidad del terminal en una tabla de información de capacidad del terminal proporcionada por un servidor y presentar la tabla y si el valor del campo de cabecera es “none”, no es necesario comunicar la información de capacidad del terminal según este campo de cabecera.
  8. 8. El método de gestión de terminal en un servicio de tipo Push según la reivindicación 1, en donde:
    la demanda de información de capacidad del terminal especifica un formato de reenvío de la información de capacidad del terminal y
    la información de capacidad del terminal reenviada está conforme al formato.
  9. 9. El método de gestión de terminal en un servicio de tipo Push según la reivindicación 8, en donde el formato especificado puede ser:
    agente usuario-perfil (ua-profile), Agente-Usuario o cuerpo de mensaje y
    si la información de capacidad del terminal se comunica por el terminal en el formato ua-profile, la gestión de las capacidades de terminal según la información de capacidad del terminal comprende las etapas siguientes:
    interaccionar con un servidor de perfiles según el perfil ua-profile comunicado por el terminal, obtener información de capacidad del terminal correspondiente memorizada en el servidor de perfiles y memorizar la información de capacidad del terminal obtenida o actualizar la información de capacidad del terminal memorizada localmente según la información de capacidad del terminal obtenida y
    si la información de capacidad del terminal se comunica por el terminal en el formato Agente-Usuario o en el formato de cuerpo de mensaje, la gestión de las capacidades de terminal según la información de capacidad del terminal comprende memorizar la información de capacidad del terminal comunicada o actualizar la información de capacidad del terminal memorizada localmente, según la información de capacidad del terminal comunicada.
  10. 10.
    El método de gestión de terminal en un servicio de tipo Push según la reivindicación 1, en donde:
    la demanda de información de capacidad del terminal transmite información de capacidad del terminal ya obtenida por un servidor y por lo tanto, el terminal que recibe la demanda comprueba la diferencia entre la información de capacidad del terminal demandada y la información de capacidad del terminal transmitida en la demanda y comunica la diferencia al servidor.
  11. 11.
    El método de gestión de terminal en un servicio de tipo Push según la reivindicación 1, en donde después de que el terminal haya recibido la demanda y haya comunicado su información de capacidad del terminal a un servidor según la demanda, el método comprende, además, la etapa siguiente:
    comunicar, por el terminal, la información de capacidad del terminal cambiada al servidor una vez que su información de capacidad haya cambiado.
  12. 12.
    El método de gestión de terminal en un servicio de tipo Push según la reivindicación 1, en donde, antes de que el terminal comunique información de capacidad del terminal memorizada localmente a un servidor, según la demanda de información de capacidad del terminal, el método comprende, además, las etapas siguientes:
    determinar, por el terminal, si el terminal es capaz de comunicar la información de capacidad del terminal demandada al servidor; si el terminal es capaz de comunicar la información de capacidad del terminal demandada, comunicar la información de capacidad del terminal demandada al servidor o, si el terminal no es capaz de comunicar la información de capacidad del terminal demanda, comunicar una respuesta de error al servidor.
  13. 13.
    El método de gestión de terminal en un servicio de tipo Push según la reivindicación 12, en donde la etapa que consiste en determinar si el terminal es capaz de comunicar la información de capacidad del terminal demanda al servidor comprende la etapa siguiente:
    determinar, por el terminal, si el terminal es capaz de comunicar la información de capacidad del terminal demandada al servidor dependiendo de si el terminal memoriza, o no, la información de capacidad del terminal demandada localmente
    o de si una política local autorice, o no, comunicar la información de capacidad del terminal.
  14. 14. Un método para comunicar información de capacidad del terminal en un servicio de tipo Push que comprende las etapas siguientes:
    detectar, por un terminal, si su información de capacidad del terminal ha sido cambiada según una demanda de información de capacidad del terminal entregada por un servidor y
    comunicar la información de capacidad del terminal cambiada al servidor una vez que la información de capacidad del 5 terminal ha sido cambiada;
    en donde dicha demanda de información de capacidad del terminal transmite información de capacidad del terminal ya obtenida por el servidor y
    10 verificar, por el terminal que recibe la demanda, la diferencia entre la información de capacidad del terminal actual y la información de capacidad del terminal transmitida en la demanda y comunicar la diferencia al servidor.
    Agente
    Agente
    receptor
    emisor Red central
    Push
    Push SIP/IP
    (1) SIP Subscribe
    (2) SIP Subscribe
    (evento: ua-profile
    (evento: ua-profile
    Información servidor)
    Información servidor)
    Agente Agente emisor Red central receptor Push SIP/IP Push
    (1) Demanda Options SIP
    (2) Demanda Options SIP (3) El terminal consulta localmente la información de capacidad requerida
    (8) La PPGactualiza la
    (5) Respuesta fallo 404 (4) Respuesta fallo 404 por la pasarela PPG
    información capacidadterminal actualmente memorizada
    (7) 200 OK (información capacidad terminal) (6) 200 OK (información capacidad terminal)
    Agente
    Agente emisor Red central receptorPush SIP/IP Push Demanda registro
    Demanda registro
    (1) Mensaje Subscribe (2) Mensaje Subscribe
    (demanda información (5) El terminal
    (demanda información
    capacidad terminal) comprueba el
    capacidad terminal)
    (10) La PPG cambio de sus actualiza la capacidades
    información capacidad (6) Mensaje error 404
    (7) Mensaje error 404 terminal
    actualmente Mensaje Notify
    Mensaje Notify
    memorizada (demanda información
    (demanda información capacidad terminal)capacidad terminal)
    Mensaje Notify Mensaje Notify
    Agente Agente Agente
    Red central
    emisor receptor receptor
    SIP/IP
    Push Push 1 Push 2
    (12) El servidor actualiza la información de capacidadterminal actualmente memorizada Demanda registro
    Demanda registro
    (1)
    MensajeSubscribe (información capacidad RA2)
    (3)
    MensajeSubscribe (información capacidad RA2)
    (7)
    Mensaje de error 404
    (11) Mensaje Notify (información capacidad RA2)
    Demanda registro
    Demanda registro
    (2) Mensaje Subscribe (información capacidad RA2)
    (4) Mensaje Subscribe
    (información capacidad RA2)
    (5) El agente receptor
    Push 1 comprueba
    (6) Mensaje de la información
    error 404 de capacidad memorizada de agente
    (10) Mensaje Notify receptor
    (información Push 2 capacidad RA2)
    Módulo gestión terminales Módulo de recepción
    Módulo de envío
    Módulo gestión terminales Módulo de recepción
    Módulo generación Módulo de demandas capacidad envío
    Módulo de envío
    Módulo procesamientocapacidad terminal
    Módulo comunicación Módulo comunicación información capacidad información de error terminal
    Módulo de consulta
    Módulo de recepción
    Módulo de recepción
    Módulo detección
    Módulo procesamiento capacidad terminal
    actualiza
    ción
    capacidad
    Módulo de envío
    Módulo para memorizar información capacidad de otros terminales
    Módulo de recepción
    Módulo procesamiento capacidad terminal
    Módulo de envío
ES08871373T 2007-12-28 2008-12-24 Un terminal, un servidor y un método para gestionar dicho terminal y un método para comunicar la información de capacidad relativa a este terminal Active ES2423509T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN2007103063888A CN101471871B (zh) 2007-12-28 2007-12-28 终端、服务器、终端管理方法和终端能力信息上报方法
CN200710306388 2007-12-28
PCT/CN2008/073677 WO2009092263A1 (zh) 2007-12-28 2008-12-24 终端、服务器、终端管理方法和终端能力信息上报方法

Publications (1)

Publication Number Publication Date
ES2423509T3 true ES2423509T3 (es) 2013-09-20

Family

ID=40829008

Family Applications (1)

Application Number Title Priority Date Filing Date
ES08871373T Active ES2423509T3 (es) 2007-12-28 2008-12-24 Un terminal, un servidor y un método para gestionar dicho terminal y un método para comunicar la información de capacidad relativa a este terminal

Country Status (4)

Country Link
EP (2) EP2575292B1 (es)
CN (1) CN101471871B (es)
ES (1) ES2423509T3 (es)
WO (1) WO2009092263A1 (es)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101790155A (zh) * 2009-12-30 2010-07-28 中兴通讯股份有限公司 一种更新移动终端安全算法的方法、装置及系统
CN102448051A (zh) * 2010-09-30 2012-05-09 重庆重邮信科通信技术有限公司 一种移动终端能力上报方法
CN102958107B (zh) * 2011-08-22 2016-11-23 华为技术有限公司 一种能力查询的方法、通信终端及应用服务器
CN103067563B (zh) * 2011-10-19 2017-02-01 中兴通讯股份有限公司 一种终端能力信息管理和发现的方法、系统及装置
EP2645666A1 (en) * 2012-03-27 2013-10-02 Telefonaktiebolaget LM Ericsson (publ) Method and capability manager for supporting provision of capabilities
CN102637211B (zh) * 2012-04-12 2014-11-05 华为技术有限公司 一种更新终端适配数据库的方法、装置及系统
FR2991839A1 (fr) * 2012-06-12 2013-12-13 France Telecom Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs
CN103581226A (zh) * 2012-07-25 2014-02-12 中兴通讯股份有限公司 一种终端能力信息同步方法、系统及设备
CN102801791A (zh) * 2012-07-25 2012-11-28 中兴通讯股份有限公司 一种基于终端能力调整业务的方法及系统
CN103581236A (zh) * 2012-07-27 2014-02-12 中兴通讯股份有限公司 一种终端能力描述信息的生成方法及系统
CN103051672B (zh) * 2012-11-21 2016-02-10 中兴通讯股份有限公司 一种异构终端环境中的终端信息获取方法及装置
CN103312817B (zh) * 2013-07-03 2016-09-07 中国矿业大学 一种wap环境下主动式信息供给方法
CN104426871A (zh) * 2013-08-29 2015-03-18 中兴通讯股份有限公司 一种远程调用的方法和装置
CN106851628B (zh) 2013-12-05 2020-08-07 华为终端有限公司 下载运营商的文件的方法及设备
EP3136252A4 (en) * 2014-05-23 2017-05-10 Huawei Technologies Co. Ltd. Euicc management method, euicc, sm platform and system
GB2527116B (en) * 2014-06-12 2017-09-20 Canon Kk Adaptative persistent push
WO2016004570A1 (zh) 2014-07-07 2016-01-14 华为技术有限公司 嵌入式通用集成电路卡管理的授权方法及装置
US20160164945A1 (en) * 2014-12-04 2016-06-09 Futurewei Technologies, Inc. Method Of Service Capability Discovery Based On Subscriptions For Service Notifications
CN105808407B (zh) * 2014-12-31 2019-09-13 华为技术有限公司 管理设备的方法、设备和设备管理控制器
CN105939210B (zh) * 2015-12-30 2019-03-15 杭州迪普科技股份有限公司 管理被管设备的方法及装置
CN105939390A (zh) * 2016-06-29 2016-09-14 深圳市轱辘软件开发有限公司 一种信息推送方法、服务器及系统
CN106656668A (zh) * 2016-12-22 2017-05-10 上海斐讯数据通信技术有限公司 一种云终端设备监控方法及系统
CN113873499B (zh) * 2017-11-23 2023-10-03 北京小米移动软件有限公司 传输配置方法及装置
CN108647085A (zh) * 2018-05-16 2018-10-12 中国联合网络通信集团有限公司 处理数据的方法、终端及系统
CN110798294A (zh) * 2018-08-03 2020-02-14 华为技术有限公司 一种获取、发送能力信息的方法及装置
CN110932830A (zh) * 2018-09-20 2020-03-27 维沃移动通信有限公司 一种能力指示方法及通信设备
CN110267301B (zh) * 2019-05-31 2022-04-29 长安大学 一种双连接系统中终端能力获取方法
WO2021258370A1 (zh) * 2020-06-24 2021-12-30 北京小米移动软件有限公司 一种通信处理方法、通信处理装置及存储介质
CN115842939A (zh) * 2021-08-05 2023-03-24 聚好看科技股份有限公司 显示设备的内容显示方法及显示设备
CN118056424A (zh) * 2021-12-08 2024-05-17 Oppo广东移动通信有限公司 能力指示方法、终端设备和网络设备

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005027460A1 (en) * 2003-09-12 2005-03-24 Telefonaktiebolaget Lm Ericsson (Publ) Combinational multimedia services
CN1278519C (zh) * 2004-07-30 2006-10-04 华为技术有限公司 将终端能力变化通知给网络的方法
FI20050149A0 (fi) * 2005-02-09 2005-02-09 Nokia Corp Push-toiminnan ohjaus viestintäjärjestelmässä
CN100448322C (zh) * 2005-08-12 2008-12-31 中国移动通信集团公司 一种获取移动终端能力更新信息的方法
KR100747468B1 (ko) * 2005-10-31 2007-08-09 엘지전자 주식회사 콤비네이션 서비스를 위한 단말 능력정보 갱신 통지 방법및 시스템

Also Published As

Publication number Publication date
EP2222024A4 (en) 2011-11-09
CN101471871B (zh) 2013-11-06
EP2222024A1 (en) 2010-08-25
CN101471871A (zh) 2009-07-01
EP2575292A1 (en) 2013-04-03
WO2009092263A1 (zh) 2009-07-30
EP2222024B1 (en) 2013-05-08
EP2575292B1 (en) 2016-06-01

Similar Documents

Publication Publication Date Title
ES2423509T3 (es) Un terminal, un servidor y un método para gestionar dicho terminal y un método para comunicar la información de capacidad relativa a este terminal
ES2436792T3 (es) Método, sistema, servidor y terminal de procesamiento de mensaje
US7181537B2 (en) Method and apparatus for routing wireless village messages in an internet protocol multimedia subsystem
US7853697B2 (en) Handling suspended network state of a terminal device
US8655357B1 (en) Systems and methods for identifying applications on a communications device
EP1470684B1 (en) Method and system for changing a subscription
EP2044747B1 (en) Technique for providing access to a media resource attached to a network-registered device
US20050155036A1 (en) Application server addressing
BRPI0514056B1 (pt) Método de verificação de registro de usuários em um sistema de comunicação móvel, sistema de comunicação e entidade de rede
CA2605475C (en) Session initiation from application servers in an ip multimedia subsystem
US20130091546A1 (en) Transmitting Authentication Information
US20050015499A1 (en) Method and apparatus for SIP user agent discovery of configuration server
FI20215027A1 (en) Network activity request error handling
US20170156045A1 (en) Notifying emergency contacts
US9832626B2 (en) Method and apparatus for maintaining a registration for an emergency service
JP2024512670A (ja) サービスベースインターフェース（ｓｂｉ）サービス運用をサポートしないネットワーク機能（ｎｆ）のためのｓｂｉサポートを提供するための方法、システム、およびコンピュータ可読媒体
KR20070025271A (ko) 아이피 기반 멀티미디어 서브시스템에서 가입자 정보유실시 발신 및 착신 호를 가능하게 하는 방법 및 장치
US20160241601A1 (en) Technique for restoring a service in a network
US20090119404A1 (en) Method for Improving Subscriber Data Integrity in an IMS Network
US9848048B2 (en) Method and apparatus for transmitting an identity
KR101075614B1 (ko) 아이피 기반 멀티미디어 서브시스템에서 가입자 정보유실시 착신호를 가능하게 하는 방법
WO2008084071A2 (en) Communication system with transparent subscriber mobility based on group registration
EP2591584B1 (en) Method and apparatus for maintaining a registration for an emergency service
JP2013012814A (ja) セッション設定方法、設定条件管理サーバ、セッション制御ノード及び移動通信システム