ES2552999T3 - Método, sistema, servidor y terminal de procesamiento de mensaje - Google Patents

Método, sistema, servidor y terminal de procesamiento de mensaje Download PDF

Info

Publication number
ES2552999T3
ES2552999T3 ES13179032.1T ES13179032T ES2552999T3 ES 2552999 T3 ES2552999 T3 ES 2552999T3 ES 13179032 T ES13179032 T ES 13179032T ES 2552999 T3 ES2552999 T3 ES 2552999T3
Authority
ES
Spain
Prior art keywords
session
information
message
server
terminal
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
ES13179032.1T
Other languages
English (en)
Inventor
Kepeng Li
Xiaoqian Chai
Linyi Tian
Fujun Ye
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 ES2552999T3 publication Critical patent/ES2552999T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/12—Application layer protocols, e.g. WAP [Wireless Application Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

Un método para procesar un mensaje, aplicable a una sesión de Sincronización de Datos, DS, que comprende: recibir, por un terminal, un mensaje de notificación de demanda de establecimiento de una sesión enviado por un servidor, en donde el mensaje de notificación incluye información de gestión de sesión relativa a la sesión; adquirir, por el terminal, la información de gestión de sesión relativa a la sesión en el mensaje de notificación y confirmar, por el terminal, el mensaje de notificación en función de la información de gestión de sesión, generar un mensaje de respuesta que incluya información de error del mensaje de notificación en función de un resultado de confirmación y enviar el mensaje de respuesta al servidor bajo la forma de un mensaje de sesión de DS, para dar instrucciones al servidor con el fin de modificar el mensaje de notificación en consecuencia de acuerdo con un tipo de error de la información de error y reenviar un mensaje de notificación modificado, en donde la información de gestión de sesión comprende información de identificador del servidor, información de autenticación e información de indicación de la sesión, en donde la información de indicación de la sesión comprende al menos una de: información de indicación de interfaz de usuario, información de objetivo, información de importancia, información de temporización, información de operación e información de política de respuesta de la sesión.

Description

imagen1
imagen2
imagen3
imagen4
imagen5
imagen6
imagen7
conexión de sesión con el servidor, el servidor no memoriza la información pertinente de la notificación, con el fin de economizar el recurso. El periodo de temporización está en una unidad de día y si es 0, ello indica que no existe ningún límite de tiempo.
<length-info> está adaptado para designar la longitud de <info> utilizando el byte como la unidad. Si es 0, ello indica que 5 la longitud de <info> es 0, es decir, no existe el campo.
<info> está adaptado para mostrar el objetivo de la notificación, a modo de ejemplo, “¿desea actualizar el firmware?”. El terminal de usuario determina si iniciar, o no, la conexión de sesión con el servidor en función de la información que se ha proporcionado.
<Op-Code> es un código de operación indicado por el servidor al terminal. A modo de ejemplo, el servidor demanda al 10 terminal la iniciación de una sesión vacía o demanda al terminal que comunique la información del dispositivo. Si se acepta la sesión, el terminal inicia la sesión correspondiente en función de la indicación de <Op-Code>.
Los valores de <Op-Code> son según se ilustra en la Tabla 2 como sigue.
Valor
Significado
000
Al terminal se le demanda iniciar una sesión vacía
001
Al terminal se le demanda comunicar la información de dispositivo completa
010
Al terminal se le demanda comunicar la información de dispositivo actualizada
011
Al terminal se le demanda comunicar la información del dispositivo
100-111
Reservado para extensión
Tabla 2
Cuando el valor es 000, el servidor demanda al cliente que inicie una sesión vacía. Una vez establecida la sesión, el
15 servidor puede adquirir la información de dispositivo del terminal utilizando una orden <Get> o iniciando una operación de sincronización.
Cuando el valor es 001, el servidor demanda al cliente que comunique la información del dispositivo completa. Durante la primera sincronización, el cliente requiere la comunicación de la información del dispositivo completa al servidor. En la sincronización subsiguiente, el cliente solamente requiere la comunicación de la información del dispositivo actualizada
20 para ahorrar el tráfico.
Cuando el valor es 010, el servidor demanda al cliente la comunicación de la información del dispositivo actualizada. El cliente puede comunicar la información del dispositivo actualizada al servidor utilizando una orden <Put> y el cliente debe memorizar un registro de actualización de la información del dispositivo.
Cuando el valor es 011, el servidor demanda al cliente no comunicar la información del dispositivo. Si el servidor no está
25 interesado en la información del dispositivo del cliente, o el servidor considera que la información del dispositivo del cliente es inútil, el servidor puede demandar al cliente no comunicar la información del dispositivo, con el fin de ahorrar el tráfico.
A continuación, el método para la expansión del mensaje de notificación de DM se describe como sigue y el formato de
la notificación de DM expandida se representa en la Tabla 3 siguiente.
imagen8
La descripción de los campos expandidos se proporciona a continuación.
5 <num-MOs>::= 4*BIT; el campo representa “el número de MOs”, <future-use>::= 4*BIT; el campo representa “reservado para extensión”, <MOI>::= <MOI-length> <MOI>; el campo representa “información del primer MOI”, <MOI-length>::= 8*BIT; el campo representa “longitud de MOI”, <MOI>::= <MOI-length> *CHAR; el campo representa “información de ID de MO”,
10 <num-MOs> está adaptado para indicar cuántos MOs están implicados en esta sesión, el siguiente MOI-MON está adaptado para mostrar la información del MO en detalle. <MOI-length> está adaptado para mostrar la longitud del MOI. <MOI> está adaptado para mostrar la información de ID del MO. El terminal puede establecer una política determinada y determinar automáticamente si iniciar, o no, la conexión de
15 sesión con el servidor en función de <MOI>, <Importance> u otra información. A modo de ejemplo, si el nivel de importancia es alto, el terminal permite automáticamente la sesión. Si el nivel de importancia es bajo, el terminal rechaza automáticamente la sesión. A modo de ejemplo, si el MOI es “urn:oma:mo:fumo:1.0”, el terminal permite también automáticamente la sesión.
En la etapa 302, se extrae el contenido en el mensaje de notificación.
20 El terminal de DS o de DM extrae el contenido transmitido en el mensaje de notificación. Conviene señalar que un mensaje de notificación puede soportar una parte del contenido, a modo de ejemplo, la información de indicación de la sesión, incluyendo el valor de la importancia de la sesión y/o la información del objetivo, la información de operación, la información de temporización (periodo de tiempo de la respuesta) de la sesión y la política de respuesta del terminal de
5
10
15
20
25
30
35
40
45
50
DS o de DM proporcionada por el servidor de DS o de DM, etc. Sin embargo, no se requiere que toda la información se transmita en un solo mensaje de notificación. Más concretamente, toda la información puede transmitirse al mismo tiempo.
En la etapa 303, el terminal de DS o de DM confirma la forma y el contenido del mensaje de notificación.
El terminal de DS o de DM confirma la forma y el contenido del mensaje de notificación que incluye, sin limitación, al procesamiento como sigue. El terminal de DS o de DM determina si el formato del mensaje de notificación es correcto, o no, determina si la versión del mensaje coincide o no, determina si el ID del servidor es incorrecto o si el ID del servidor existe. Realiza la autenticación de si el Digest se transmite en función de la información de autenticación y determina la importancia de la sesión en función del valor de importancia adquirido de la sesión o determina la importancia de la sesión en función del objetivo adquirido de la sesión y el estado actual del terminal, tal como si el terminal está ocupado,
o no, o si se realiza o no, la misma sesión o visualiza la información de objetivo adquirida de la sesión al usuario y determina la importancia de la sesión en función de si el usuario rechaza la sesión o recibe la sesión. El terminal de DS
o de DM determina también si adoptar la política de respuesta del terminal de DS o de DM que se proporciona por el servidor de DS o de DM al terminal de DS o DM.
En la etapa 304, se determina cómo responder en función de la política. Si se inicia la sesión de DS o de DM, el terminal inicia la sesión de DS o de DM o no realiza ningún procesamiento; de no ser así, el procesamiento prosigue con la etapa
306.
La política puede ser la política de respuesta memorizada por el terminal de DS o de DM por anticipado y puede ser también la política de respuesta entregada por el servidor de DS o de DM al terminal de DS o de DM. La política del terminal de DS o de DM incluye, sin limitación, varias situaciones como sigue. 1. Cuando el mensaje de notificación se recibe satisfactoriamente, dicho de otro modo, indica que la versión del mensaje de notificación es correcta, el formato es correcto, el ID del servidor es correcto y la validación de Digest se consigue y cuando la sesión se considera que es relativamente importante y puede ser recibida en función de la información de indicación en la información de gestión de sesión y/o el estado actual del terminal, el mensaje requiere que se responda. 2. Cuando el mensaje de notificación se recibe satisfactoriamente, dicho de otro modo, indica que la versión del mensaje de notificación es correcta, el formato es correcto, el ID del servidor de DS o de DM es correcto y se supera la validación de Digest y cuando se considera que la sesión es relativamente importante, el mensaje requiere que no se responda. 3. Cuando el mensaje de notificación se recibe satisfactoriamente, dicho de otro modo, indica que la versión del mensaje de notificación es correcta, el formato es correcto, el ID del servidor es correcto y se supera la validación de Digest, pero cuando la sesión se considera que no es importante en función de la información de indicación en la información de gestión de sesión y/o el estado actual del terminal y se rechaza la sesión, el mensaje requiere que no se responda. 4. Cuando el mensaje recibido tiene una de las situaciones en que la versión del mensaje de notificación es incorrecta, el formato es incorrecto, el ID del servidor de DS o de DM es incorrecto y no se supera la validación de Digest, pero cuando la sesión se considera que es relativamente importante y puede recibirse en función de la información de indicación en la información de gestión de sesión y/o el estado actual del terminal, el mensaje requiere que se responda. 5. Cuando el mensaje recibido tiene una de las situaciones en que la versión es incorrecta, el formato es incorrecto, el ID del servidor de DS o de DM es incorrecta y no se supera la validación de Digest, pero cuando la sesión se considera que no es importante en función de la información de indicación en la información de gestión de sesión y/o el estado actual del terminal y se rechaza la sesión, el mensaje requiere que se responda. Durante la aplicación práctica, el terminal de DS o de DM solicita al usuario y el usuario decide responder o no hacerlo. Si, en la etapa 303, el terminal determina adoptar la política de respuesta del terminal de DS o de DM que se proporciona por el servidor de DS o de DM al terminal de DS o de DM, el terminal realiza la respuesta correspondiente adoptando la política de respuesta proporcionada por el servidor. Durante la aplicación práctica, se produce un fallo operativo directo y el mensaje requiere su respuesta, por lo que se puede omitir la etapa.
En la etapa 305, se determina la forma y contenido del mensaje de respuesta y se genera el mensaje de respuesta.
Cuando se determina que el mensaje requiere su respuesta según la etapa 304, en función de los diferentes resultados de análisis y de autenticación en el mensaje en la etapa 303 y las diferentes formas de soporte del mensaje de notificación, la forma y el contenido del mensaje de respuesta se determinan en conformidad con la regla descrita como sigue.
Diferentes formas y contenidos del mensaje de respuesta se determinan, respectivamente, en función de las cuatro situaciones que requieren la respuesta.
imagen9
Haciendo referencia a la Figura 4, un diagrama de flujo de señalización de la primera forma de realización del método según la presente invención se ilustra con la inclusión de las etapas siguientes.
En la etapa 401, el servidor de DS o de DM proporciona la información pertinente de gestión de sesión y demanda al servidor de notificación para proporcionar el mensaje de notificación al terminal de DS o de DM. El servidor de notificación puede ponerse en práctica como un servidor de mensajes cortos, un servidor de tipo OTA PUSH o un servidor SIP PUSH, etc.
El contenido de información de gestión pertinente se describió anteriormente, por lo que aquí no se repite.
En la etapa 402, el servidor de notificación proporciona el mensaje de notificación al terminal de DS o de DM y demanda la conexión de sesión. El mensaje de notificación incluye la finalidad de gestión de sesión, la importancia y otra información y el modo de entrada puede ser en la forma de un mensaje corto y la OTA PUSH, etc.
En la etapa 403, el cliente de notificación, en el terminal, transfiere el mensaje de notificación al cliente de DS o de DM.
En la etapa 404, el cliente de DS o de DM, en el terminal de DS o de DM, extrae el contenido en el mensaje, tal como el ID de servidor de DS o de DM, realiza la autenticación Digest en el mensaje de notificación, analiza el formato del mensaje y determina la importancia de la sesión.
El terminal de DS o de DM determina si el mensaje requiere, o no, una respuesta en conformidad con la política antes citada establecida y memorizada en el terminal de DS o de DM por anticipado. A modo de ejemplo, si el ID del servidor de DS o de DM es incorrecto, no se supera la autenticación Digest o el formato de la notificación es incorrecto, el terminal responde con la información de error correspondiente al servidor como la respuesta del mensaje de notificación.
Si el ID del servidor de DS o de DM es correcto, se supera la autenticación Digest o el formato de la notificación es correcto, el terminal puede responder con la información correspondiente, a modo de ejemplo, la información que indica que el terminal recibe satisfactoriamente el mensaje, al servidor como la respuesta del mensaje de notificación.
En la etapa 405, el cliente de DS o de DM, en el terminal de DS o de DM, genera el código de estado y el mensaje de respuesta con el fin de indicar si el mensaje de notificación se recibe satisfactoriamente.
Si se recibe satisfactoriamente el mensaje, el terminal responde con la información 200 (satisfactoria), si el ID del servidor de DS o de DM es incorrecto, no se supera la autenticación Digest o el formato de la notificación es incorrecto, el terminal responde con el código de error correspondiente al servidor de notificación y la Tabla correspondiente detallada del código de estado se muestra en la Tabla 5.
En la etapa 406, el cliente de DS o de DM transfiere al mensaje de respuesta al cliente de notificación.
Conviene señalar que antes de que el cliente de DS o de DM determine transferir, o no, el mensaje de respuesta al cliente de notificación, es necesario determinar si responder con el mensaje de notificación en función de la forma de soporte del mensaje de notificación y el número de respuesta del servidor de notificación.
En la etapa 407, el cliente de notificación empaqueta el mensaje de respuesta para el formato especificado, según se indica en la Tabla 4 como sigue.
En la etapa 408, el cliente de notificación transfiere el mensaje de respuesta empaquetado al servidor de notificación.
En la etapa 409, el servidor de notificación realiza el procesamiento subsiguiente en función del mensaje de respuesta.
Si el código de estado, reenviado desde el terminal, indica que el mensaje se recibe satisfactoriamente, el servidor de
imagen10
0010
La versión no está adaptada
0011
El formato es error
0100
El ID del servidor no existe
0101
No especificado es error
0111
El terminal rechaza la sesión
0110-1111
Reservado para extensión
Tabla 5
Conviene señalar que el establecimiento del formato o la Tabla se proporciona a modo de ejemplo y en la presente invención, no se excluyen otros establecimientos similares, por lo que la presente invención no está limitada en este sentido.
5 Además, con el fin de permitir al servidor entender adecuadamente que el mensaje enviado por el terminal es el mensaje de respuesta de la notificación, el tipo de contenido del mensaje de respuesta puede definirse como siendo:
application/vnd.syncml.dm.response application/vnd.syncml.ds.response.
El servidor puede conocer la situación de recibir el mensaje por el terminal en función de la información de código de estado recibida.
10 Si el terminal de DS o de DM no puede responder con el mensaje de notificación debido a la forma de soporte u otros motivos, a modo de ejemplo, el número de respuesta del servidor de notificación no puede adquirirse o el servidor de notificación proporciona el mensaje de notificación por intermedio de WAP PUSH, el terminal no puede responder al mensaje de notificación en el modo WAP PUSH; en este caso, el terminal puede responder al mensaje al servidor en la manera de sesión de DS o de DM; a modo de ejemplo, el terminal puede responder la información de error
15 correspondiente del servidor de notificación o la información que indica que se rechaza la sesión. Conviene señalar que si el terminal de DS o de DM no supera la autenticación Digest del mensaje de notificación, o la información del ID del servidor de DS o de DM se encuentra que es incorrecta, el terminal no inicia la sesión de DS o de DM para comunicar la información de error correspondiente puesto que el servidor no puede ser objeto de confianza. Si el formato de la notificación es incorrecto, la versión no es coincidente y existen otros errores, el terminal puede comunicar la
20 información de error en la manera de sesión de DS o de DM. Cuando el mensaje se responde al servidor en la manera de sesión de DS o de DM, Alert Type requiere que se defina en el protocolo para comunicar la información especificada, a modo de ejemplo, org.openmobilealliance.dm.notification-error indica el código de error pertinente en <Data>.
La situación detallada puede obtenerse con referencia a la Figura 5, un diagrama de flujo de señalización de respuesta con el mensaje por intermedio del cliente de DS o de DM, según la segunda forma de realización del método de la
25 presente invención y el proceso detallado se muestra como sigue.
Las etapas se describen como sigue.
En la etapa 501, el servidor de DS o de DM proporciona la información pertinente de gestión de sesión y demanda al servidor de notificación que proporcione el mensaje de notificación al terminal de DS o de DM. El servidor de notificación puede ponerse en práctica como el servidor de mensajes cortos, el servidor OTA PUSH o el servidor SIP PUSH, etc.
30 El contenido de información de gestión pertinente se describió anteriormente, por lo que aquí no se repite.
5
10
15
20
25
30
35
En la etapa 502, el servidor de notificación proporciona el mensaje de notificación al terminal de DS o de DM y demanda la conexión de sesión. El mensaje de notificación incluye el objetivo de gestión de sesión, la importancia y otra información la manera de entrega puede ser en la forma de mensaje corto y OTA PUSH, etc.
En la etapa 503, el cliente de notificación, en el terminal, transfiere el mensaje de notificación al cliente de DS o de DM.
En la etapa 504, el cliente de DS o de DM, en el terminal de DS o de DM, extrae el contenido en el mensaje, tal como el ID del servidor de DS o de DM, realiza la autenticación Digest del mensaje de notificación, analiza el formato del mensaje y determina la importancia de la sesión, etc.
El terminal de DS o de DM determina si el mensaje requiere responderse en conformidad con la política antes citada que se establece y memoriza en el terminal de DS o de DM por anticipado. A modo de ejemplo, si el formato de la notificación es incorrecto y la información de la versión es incorrecta, el terminal responde con la información de error correspondiente al servidor de DS o de DM.
Si el ID del servidor de DS o de DM es correcto, se supera la autenticación Digest, el formato de la notificación es correcto y la versión es correcta, el terminal puede responder con la información correspondiente, a modo de ejemplo, la información que indica que el terminal recibe satisfactoriamente el mensaje, al servidor de DS o de DM.
Si el terminal considera que la importancia de la sesión no satisface la política establecida, el terminal envía el mensaje de respuesta de rechazo de la sesión al servidor de DS o de DM.
En la etapa 506, cuando el cliente de DS o de DM determina que el mensaje requiere responderse en conformidad con la política correspondiente, confirmando la forma de soporte del mensaje de notificación, el número de respuesta del servidor de notificación y otra información, el cliente de DS o de DM determina no responder en la forma de notificación
o el cliente de DS o de DM selecciona directamente responder con el mensaje en la manera de sesión de DS o de DM. El contenido del mensaje de respuesta incluye que el formato del mensaje es incorrecto, la versión del mensaje es incorrecta, el mensaje de notificación se recibe satisfactoriamente o se rechaza la sesión.
De modo opcional, el cliente de DS o de DM puede visualizar la información pertinente en el mensaje de notificación para el usuario y demanda al usuario que confirme si se rechaza, o no, la sesión por una interfaz de usuario (UI).
En la etapa 507, el usuario determina rechazar la sesión mediante una interfaz de entrada.
En la etapa 508, el terminal de DS o de DM inicia la conexión de sesión al servidor de DS o de DM y envía el mensaje de respuesta de rechazo de la sesión.
De modo opcional, si el terminal acepta la sesión, el terminal inicia la operación de sesión correspondiente en función de la indicación en el mensaje de notificación, a modo de ejemplo, el terminal inicia una sesión vacía o comunica la información del dispositivo.
En la etapa 508, el terminal de DS o de DM requiere iniciar una sesión especial para notificar al servidor que el terminal rechaza la sesión. Un Alert type requiere que se defina para notificar al servidor la utilización del mensaje y el tipo puede definirse como: org.openmobilealliance.dm.refuse-session.
La realización, a modo de ejemplo, del mensaje es como sigue.
<Alert>; el campo representa “orden de alerta”
<CmdID>1</CmdID>; el campo representa “ID de número de secuencia de la orden”
<Data>1226</Data>; el campo representa “tipo de alerta 1226 que representa la alerta genérica”
<Item>: el campo representa “elemento de datos”, <Meta>: el campo representa “información de descripción del elemento de datos”, <Type xmlns=”syncml:metinf”>; el campo representa “tipo de elemento de datos” org.openmobilealliance.dm.refuse-session: el campo representa “la sesión es rechazada”,
5 </Type> <Format xmlns=”syncml:metinf”>b64</Format>: formato de datos de <Data>, </Meta>
<Data>abc… </Data>: el campo representa “contenido de datos”, </Item> 10 </Alert>
O bien, un tipo de alerta se expande por separado, a modo de ejemplo, Alert 1220, que se adapta para comunicar la información que indica que la sesión es rechazada al servidor. La realización, a modo de ejemplo, del mensaje es como sigue. <Alert>: el campo representa “orden de notificación”,
15 <CmdID>1</CmdID> <Data>1220</Data>: el campo representa “tipo de notificación, que representa que el terminal rechaza la sesión”, <Item> … </Item> </Alert>
20 Además, la información que indica que el formato de mensaje incorrecto, la versión del mensaje es incorrecta y el mensaje de notificación se recibe satisfactoriamente puede transmitirse en el elemento de Alert en el mensaje. Con el fin de ahorrar el tráfico, después de recibir el mensaje de respuesta de rechazo de la sesión, el servidor de DS o
de DM puede no responder con el mensaje. Según la descripción de la forma de realización antes citada, puede deducirse que el terminal de DS o de DM conoce si 25 la sesión iniciada por el servidor de DS o de DM es, o no, importante por anticipado mediante el mensaje de notificación, aún cuando el mensaje de notificación entregado por el servidor indique que la sesión es importante, el terminal determina si la sesión es, o no, importante en función de su estado operativo. Cuando se determina que la sesión no es importante, el terminal envía directamente la información de respuesta de rechazo de la sesión al servidor, impidiendo así que el servidor de DS o de DM envíe repetidamente el mensaje de notificación antes de informarse de que el
terminal inicia la sesión y evita desperdiciar el recurso de la red y de procesamiento del servidor. Por lo tanto, el terminal conoce el objetivo y la importancia de la sesión por anticipado, por lo que se evita la situación de que la sesión en curso se rechaza cuando se detecta que la importancia de la sesión no cumple el requisito, evitando de este modo el desperdicio de los recursos de procesamiento del terminal y los recursos de transmisión de la red.
5 En un ejemplo, el agente SIP push que sirve como el servidor de notificación, envía el mensaje de notificación, el método para procesar el mensaje aplicable a la sesión de DS o de DM, según la presente invención que se describe con más detalle, de modo que los expertos en esta técnica puedan entender la solución de la presente invención con mayor claridad. En este ejemplo, un agente remitente de SIP push es el servidor de notificación y un agente receptor de SIP push es el cliente de notificación. El contenido de push incluye el mensaje de notificación. El proceso detallado puede
10 obtenerse con referencia a la Figura 6, que incluye las etapas siguientes.
En la etapa 601, el servidor de DS o de DM transfiere la demanda de notificación al agente remitente SIP push y demanda el envío del mensaje de notificación.
En la etapa 602, el servidor del agente remitente SIP push entrega el contenido de la notificación al terminal de DS o de DM.
15 El servidor del agente remitente SIP push entrega el mensaje de notificación al agente receptor SIP push (es decir, el cliente de notificación) en el terminal de DS o de DM utilizando un protocolo SIP push.
El contenido del Digest y de la cabecera de mensaje de la notificación, en este ejemplo, se indica en la Tabla 6 como sigue.
imagen11
20 Tabla 6 El contenido del cuerpo de la parte de cuerpo del mensaje de la notificación se ilustra en la Tabla 7 como sigue.
imagen12
Tabla 7
El contenido de la notificación se entrega utilizando el método MESSAGE en el SIP y la realización, a modo de ejemplo, 25 del mensaje SIP se proporciona como sigue.
imagen13
imagen14
imagen15

Claims (1)

  1. imagen1
    imagen2
ES13179032.1T 2007-07-24 2008-06-13 Método, sistema, servidor y terminal de procesamiento de mensaje Active ES2552999T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2007100752893A CN101355524B (zh) 2007-07-24 2007-07-24 一种消息处理方法、系统、服务器和终端
CN200710075289 2007-07-24

Publications (1)

Publication Number Publication Date
ES2552999T3 true ES2552999T3 (es) 2015-12-03

Family

ID=40281001

Family Applications (2)

Application Number Title Priority Date Filing Date
ES08757707.8T Active ES2436792T3 (es) 2007-07-24 2008-06-13 Método, sistema, servidor y terminal de procesamiento de mensaje
ES13179032.1T Active ES2552999T3 (es) 2007-07-24 2008-06-13 Método, sistema, servidor y terminal de procesamiento de mensaje

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES08757707.8T Active ES2436792T3 (es) 2007-07-24 2008-06-13 Método, sistema, servidor y terminal de procesamiento de mensaje

Country Status (7)

Country Link
US (2) US8019877B2 (es)
EP (2) EP2091210B1 (es)
JP (2) JP2010519812A (es)
KR (1) KR101031828B1 (es)
CN (1) CN101355524B (es)
ES (2) ES2436792T3 (es)
WO (2) WO2009012677A1 (es)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101340286B (zh) * 2007-05-30 2011-03-30 华为技术有限公司 会话连接发起方法及设备
CN102308532B (zh) * 2009-05-21 2013-10-09 华为终端有限公司 点到多点推送消息处理方法、系统及服务器
US20110055076A1 (en) * 2009-08-25 2011-03-03 Greg Trifiletti Response to alert message
US20110295947A1 (en) * 2010-06-01 2011-12-01 Htc Corporation Communication apparatus and method thereof
CN101909282B (zh) * 2010-08-20 2014-11-05 中兴通讯股份有限公司 终端操作的触发方法、装置及系统
US8799378B2 (en) * 2010-12-17 2014-08-05 Microsoft Corporation Non-greedy consumption by execution blocks in dataflow networks
CN102571704B (zh) * 2010-12-24 2015-05-27 华为终端有限公司 管理会话的发起和通知方法、被管理终端及管理服务器
US8676258B2 (en) * 2011-02-15 2014-03-18 David Goren Systems and methods of transferring user information to different devices
CN102651860B (zh) * 2011-02-24 2014-12-31 华为终端有限公司 一种设备管理方法及装置
CN102130910B (zh) 2011-02-28 2015-04-29 华为技术有限公司 Tcp代理插入和卸载方法及业务网关设备
US9531827B1 (en) 2011-06-14 2016-12-27 Urban Airship, Inc. Push notification delivery system with feedback analysis
US8554855B1 (en) 2011-06-14 2013-10-08 Urban Airship, Inc. Push notification delivery system
US8731523B1 (en) 2011-06-14 2014-05-20 Urban Airship, Inc. Push notification delivery system with feedback analysis
CN103037322A (zh) * 2011-10-05 2013-04-10 宏达国际电子股份有限公司 减少客户端及服务器间讯息传输的方法及其通信装置
US20130091198A1 (en) * 2011-10-05 2013-04-11 Htc Corporation Method of Reducing Message Transmission between DM Client and DM Server and Related Communication Device
KR101956634B1 (ko) 2012-01-03 2019-03-11 삼성전자 주식회사 행동 정보 알림 서비스 시스템 및 행동 정보 알림 서비스 방법
US9075953B2 (en) 2012-07-31 2015-07-07 At&T Intellectual Property I, L.P. Method and apparatus for providing notification of detected error conditions in a network
WO2014030905A1 (ko) * 2012-08-20 2014-02-27 엘지전자 주식회사 무선 통신 시스템에서 서버를 활성화 또는 비활성화하기 위한 방법 및 장치
US8924443B2 (en) * 2012-10-05 2014-12-30 Gary Robin Maze Document management systems and methods
CN103873538A (zh) * 2012-12-18 2014-06-18 中兴通讯股份有限公司 基于dm协议的服务端与终端的通信方法及系统
US9495558B2 (en) * 2013-03-26 2016-11-15 Google Inc. Systems, methods, and computer program products for managing access control
US9053165B2 (en) * 2013-07-08 2015-06-09 Dropbox, Inc. Structured content item synchronization
US10091287B2 (en) 2014-04-08 2018-10-02 Dropbox, Inc. Determining presence in an application accessing shared and synchronized content
US10171579B2 (en) 2014-04-08 2019-01-01 Dropbox, Inc. Managing presence among devices accessing shared and synchronized content
US10270871B2 (en) 2014-04-08 2019-04-23 Dropbox, Inc. Browser display of native application presence and interaction data
US9998555B2 (en) 2014-04-08 2018-06-12 Dropbox, Inc. Displaying presence in an application accessing shared and synchronized content
US9846528B2 (en) 2015-03-02 2017-12-19 Dropbox, Inc. Native application collaboration
CN106161580A (zh) * 2015-04-28 2016-11-23 中兴通讯股份有限公司 一种连接状态控制方法、装置及系统
CN105245534A (zh) * 2015-10-22 2016-01-13 中国移动通信集团江苏有限公司 一种呼叫结果反馈方法、服务器、终端、系统
CN106656729B (zh) * 2015-10-30 2019-11-22 阿里巴巴集团控股有限公司 一种发送信息的方法及装置
US10248933B2 (en) 2015-12-29 2019-04-02 Dropbox, Inc. Content item activity feed for presenting events associated with content items
US10620811B2 (en) 2015-12-30 2020-04-14 Dropbox, Inc. Native application collaboration
US10382502B2 (en) 2016-04-04 2019-08-13 Dropbox, Inc. Change comments for synchronized content items
CN110915264B (zh) * 2017-08-04 2021-02-23 华为技术有限公司 无线通信中的会话处理方法及终端设备
CN111083127B (zh) * 2019-12-05 2021-11-09 达闼机器人有限公司 会话管理方法、电子设备及计算机可读存储介质
CN112231566B (zh) * 2020-10-16 2023-11-28 成都知道创宇信息技术有限公司 信息推送方法、装置、系统和可读存储介质
CN112737922B (zh) * 2020-12-23 2023-04-14 江苏苏宁云计算有限公司 通讯方法、装置、计算机设备和存储介质
CN112866361A (zh) * 2021-01-06 2021-05-28 戴振卿 一种工业数据的安全传输方法
CN112925779A (zh) * 2021-03-02 2021-06-08 重庆度小满优扬科技有限公司 一种报文回执修改方法及装置
CN113098726B (zh) * 2021-06-10 2021-09-03 深圳艾灵网络有限公司 网络切片方法、设备及存储介质

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9826158D0 (en) 1998-11-27 1999-01-20 British Telecomm Anounced session control
US6882659B1 (en) * 1999-09-20 2005-04-19 Telefonaktiebolaget Lm Ericsson (Publ) Wide area network synchronization
JP2001169341A (ja) * 1999-09-29 2001-06-22 Fujitsu Ltd 移動通信サービス提供システム、移動通信サービス提供方法、認証装置、およびホームエージェント装置
JP4076701B2 (ja) * 2000-04-14 2008-04-16 富士通株式会社 ノード装置
US7765316B1 (en) * 2000-10-10 2010-07-27 Intel Corporation Scheduling the uploading of information from a client to a server
JP2002133306A (ja) * 2000-10-20 2002-05-10 Canon Inc 情報処理装置、情報処理システム、情報処理方法、及び記憶媒体
JP3944229B2 (ja) * 2000-12-28 2007-07-11 フューチャーアーキテクト株式会社 フレームワークシステム
CN1291333C (zh) * 2001-09-05 2006-12-20 松下电器产业株式会社 同步消息处理方法
US7155521B2 (en) * 2001-10-09 2006-12-26 Nokia Corporation Starting a session in a synchronization system
KR100866076B1 (ko) * 2002-04-30 2008-10-30 노키아 코포레이션 트리 데이터 교환의 관리를 위한 방법 및 장치
JP2007525087A (ja) * 2003-06-27 2007-08-30 アコニクス・システムズ・インコーポレイテッド アクティブ受信及びアクティブ警告でのコンテクスト依存の転送
FI116958B (fi) * 2003-07-01 2006-04-13 Nokia Corp Hallintasolmujen määrittäminen laitteenhallintajärjestelmässä
WO2005102017A2 (en) * 2004-01-15 2005-11-03 Nokia Corporation Techniques for updating security-related parameters for mobile stations
US7889869B2 (en) * 2004-08-20 2011-02-15 Nokia Corporation Methods and apparatus to integrate mobile communications device management with web browsing
SE528373C2 (sv) * 2004-08-25 2006-10-31 Smarttrust Ab Förfarande och system för apparathantering
FI20041634A0 (fi) 2004-12-20 2004-12-20 Nokia Corp Tarjontaistunnon muodostaminen kommunikaatiojärjestelmässä
JP4432814B2 (ja) * 2005-03-25 2010-03-17 ヤマハ株式会社 演奏データ通信管理システム及び演奏データ通信管理装置
US7734737B2 (en) * 2005-05-26 2010-06-08 Nokia Corporation Device management with configuration information
KR100941540B1 (ko) * 2005-06-02 2010-02-10 엘지전자 주식회사 장치관리 시스템 및 그 시스템에서의 설정-값 세팅 방법
US20070027971A1 (en) * 2005-07-26 2007-02-01 Sunil Marolia Device management network with notifications comprising multiple choice prompts
US20070093243A1 (en) * 2005-10-25 2007-04-26 Vivek Kapadekar Device management system
EP1955481B1 (en) * 2005-12-02 2018-11-07 LG Electronics Inc. Device management method using broadcast channel
US8437751B2 (en) * 2006-04-25 2013-05-07 Core Wireless Licensing S.A.R.L. Method, apparatus and computer program product for providing confirmed over-the-air terminal configuration
US7721003B2 (en) * 2007-02-02 2010-05-18 International Business Machines Corporation System and method to synchronize OSGi bundle inventories between an OSGi bundle server and a client
US9462060B2 (en) * 2007-04-23 2016-10-04 Alcatel Lucent System and method for sending notification message to a mobile station using session initiation protocol (SIP)

Also Published As

Publication number Publication date
KR101031828B1 (ko) 2011-04-29
CN101355524A (zh) 2009-01-28
WO2009012730A1 (en) 2009-01-29
US8341274B2 (en) 2012-12-25
JP5249405B2 (ja) 2013-07-31
JP2012085346A (ja) 2012-04-26
JP2010519812A (ja) 2010-06-03
ES2436792T3 (es) 2014-01-07
KR20090086447A (ko) 2009-08-12
EP2091210A1 (en) 2009-08-19
US20110296042A1 (en) 2011-12-01
EP2091210A4 (en) 2010-09-01
WO2009012677A1 (en) 2009-01-29
CN101355524B (zh) 2013-10-09
US20090265471A1 (en) 2009-10-22
EP2661052B1 (en) 2015-08-12
US8019877B2 (en) 2011-09-13
EP2661052A1 (en) 2013-11-06
EP2091210B1 (en) 2013-09-04

Similar Documents

Publication Publication Date Title
ES2552999T3 (es) Método, sistema, servidor y terminal de procesamiento de mensaje
CN116057924A (zh) 用于提供网络功能发现服务增强的方法、系统和计算机可读介质
CN102395115A (zh) 用于在融合ip消息业务中管理消息线程的方法和系统
EP2227047A1 (en) Device determination
US20180063879A1 (en) Apparatus and method for interoperation between internet-of-things devices
CN101459696A (zh) 移动机、内容发送系统和内容发送方法
KR20130076808A (ko) 장치 관리 서버가 직접 접근할 수 없는 장치들을 관리하기 위한 기술들
US9942281B2 (en) Group communication in communication system
EP2654242B1 (en) Device management method and apparatus
US9634865B2 (en) Method of providing quick answer service in SIP message service system
CN102549568B (zh) 用于能够实现xml文档的修改的方法和设备
CN106576285B (zh) 一种apn配置方法、用户设备和配置服务器
EP3843363A1 (en) Session management function and method of operating a session management function
CN104981791A (zh) 移动发送方控制的数据访问和数据删除方法和系统
KR20180025174A (ko) 사물인터넷 디바이스 연동 장치 및 방법
US20130091287A1 (en) System for contact subscription invitations in a cross-domain converged address book system
CN116420363A (zh) 用于支持用户简档和策略信息的迁移的方法、系统和计算机可读介质
CN108235281A (zh) 应用实体创建资源和注册方法、通信节点设备及终端设备
CN112368991A (zh) 用于归属移动通信网络和拜访移动通信网络中的ip多媒体子系统呼叫的改进的处置的方法
WO2015117330A1 (zh) 一种删除通告资源的方法和公共业务实体
CN112153580B (zh) 设置mcptt群组的方法、设备及系统
CN102075498A (zh) 一种用于配置目录信息的方法及装置
CN111512612A (zh) 用于远程管理连接到住宅网关的设备的方法
WO2016090933A1 (zh) 应用通告资源的创建方法及装置
CN108322501A (zh) 一种消息推送方法和装置