GESTION DE L'ACCES AU STATUT D'UNE RESSOURCE MANAGING ACCESS TO THE STATUS OF A RESOURCE
La présente invention concerne la gestion de l'accès d'un terminal d'utilisateur, connecté à un réseau d'accès, au statut d'une ressource physique et/ou logicielle gérée par un gestionnaire. L'invention s'applique avantageusement, mais non limitativement, dans les réseaux de communication de type IP (« Internet Protocol ») mettant en oeuvre un protocole d'ouverture, de modification, et de fermeture de session SIP (« Session Initiation Protocol »). Selon le protocole SIP, un utilisateur a la possibilité d'accéder au statut d'une ressource physique et/ou logicielle en envoyant depuis son terminal une requête « SIP SUBSCRIBE » vers un gestionnaire de la ressource, qui est généralement un serveur d'un opérateur de télécommunications. Une ressource physique est notamment un dispositif de traitement de données, par exemple, un ordinateur personnel fixe ou portable, un radiotéléphone, un assistant numérique (« PDA »), une carte à puce, etc. Le statut du dispositif est typiquement son état électrique, ou l'état de présence de l'utilisateur du dispositif Une ressource logicielle est notamment une application logicielle apte à posséder un statut, telle une application de messagerie. Le statut d'une telle application de messagerie est typiquement une alerte à l'utilisateur lui indiquant qu'un nouveau message a été déposé dans la 2 0 messagerie. La norme « OMA-TS-Presence_SIMPLE-V2_0 » de l'organisme de standardisation OMA (« Open Mobile Alliance ») permet à un utilisateur, appelé «Watcher », de souscrire à une information sur l'état de présence d'un autre utilisateur, appelé « Presentity ». Cette souscription est déclenchée par l'envoi depuis le terminal du «Watcher » vers 25 le gestionnaire du terminal du « Presentity », appelé «Enabler de Présence » d'une requête « SIP SUBSCRIBE ». Si cette souscription est acceptée, 1'« Enabler de Présence » conserve un contexte de la souscription. A chaque modification de l'état de présence du «Presentity », une notification est envoyée par 1«< Enabler de Présence » vers le « Watcher » sous forme d'une requête « SIP NOTIFY ». Une telle notification est également envoyée à chaque rafraîchissement de la 3 0 souscription. Selon le protocole SIP, cette requête est acquittée par le « Watcher ». Pour recevoir cette notification et envoyer l'acquittement correspondant, il est nécessaire que le terminal du « Watcher » dispose d'une connectivité au réseau. Dans le cas où le terminal du « Watcher » ne dispose pas de cette connectivité au 35 réseau lors du traitement de la notification, 1«< Enabler de Présence » ne peut pas recevoir d'acquittement et la transaction de la requête « SIP NOTIFY » est alors considérée en erreur. Suite à cet échec, il est recommandé à r<< Enabler de Présence » de clôturer le contexte lié à la souscription du « Watcher ». Tel est le cas notamment dans la norme « IETF RFC 3265 » Cette suppression systématique du contexte du «Watcher » est un comportement souhaitable dans un environnement dans lequel la connectivité est considérée comme stable, par exemple lorsque le « Watcher » accède au réseau IP avec un accès de type xDSL. Cependant, cette suppression systématique n'est pas souhaitable dans un environnement dans lequel la connectivité est considérée comme moins stable, notamment lorsque le « Watcher » accède au réseau IP avec un accès mobile. En effet, dans ce cas, la réception de la notification « SIP NOTIFY » par le terminal du « Watcher » n'est pas garantie, par exemple en cas de perte de la couverture radio. Plus particulièrement, lorsque le « Watcher » retrouve la connexion de son terminal mobile au réseau, il n'est pas conscient de la suppression de sa souscription et il ne reçoit ainsi plus de notification de modification de l'état de présence du «Presentity» auquel il a souscrit. L'utilisateur a alors une mauvaise expérience du service d'accès à l'état de présence. The present invention relates to the management of the access of a user terminal, connected to an access network, to the status of a physical and / or software resource managed by a manager. The invention applies advantageously, but not exclusively, in the communication networks of the IP ("Internet Protocol") type implementing a protocol for opening, modifying, and closing session SIP ("Session Initiation Protocol"). ). According to the SIP protocol, a user has the possibility of accessing the status of a physical and / or software resource by sending from his terminal a "SIP SUBSCRIBE" request to a resource manager, which is generally a server of a telecommunications operator. A physical resource is in particular a data processing device, for example a fixed or portable personal computer, a radiotelephone, a digital assistant ("PDA"), a smart card, etc. The status of the device is typically its electrical state, or the state of presence of the user of the device A software resource is in particular a software application capable of having a status, such as a messaging application. The status of such an email application is typically an alert to the user that a new message has been dropped in the mail. The OMA-TS-Presence_SIMPLE-V2_0 standard of the Open Mobile Alliance (OMA) standardization organization allows a user, called "Watcher", to subscribe to information about the presence status of another user, called "Presentity". This subscription is triggered by the sending from the terminal of the "Watcher" to the terminal manager of the "Presentity", called "Enabler of Presence" of a request "SIP SUBSCRIBE". If this subscription is accepted, the "Enabler of Presence" keeps a context of the subscription. At each change of the presence state of the "Presentity", a notification is sent by 1 "Presence Enabler" to the "Watcher" in the form of a "SIP NOTIFY" request. Such notification is also sent to each refresh of the subscription. According to the SIP protocol, this request is acknowledged by the "Watcher". To receive this notification and send the corresponding acknowledgment, it is necessary that the terminal of the "Watcher" has connectivity to the network. In the case where the terminal of the "Watcher" does not have this connectivity to the network during the processing of the notification, 1 "<Presence Enabler" can not receive an acknowledgment and the transaction of the request "SIP NOTIFY" is then considered to be in error. Following this failure, it is recommended that r << Enabler of Presence >> close the context related to the subscription of the "Watcher". This is particularly the case in the "IETF RFC 3265" standard. This systematic suppression of the "Watcher" context is a desirable behavior in an environment in which the connectivity is considered stable, for example when the "Watcher" accesses the IP network with xDSL type access. However, this systematic deletion is not desirable in an environment in which connectivity is considered less stable, especially when the "Watcher" accesses the IP network with mobile access. Indeed, in this case, the receipt of the notification "SIP NOTIFY" by the terminal of the "Watcher" is not guaranteed, for example in case of loss of radio coverage. More particularly, when the "Watcher" finds the connection of his mobile terminal to the network, he is not aware of the deletion of his subscription and he thus no longer receives notification of modification of the presence status of "Presentity" to which he has subscribed. The user then has a bad experience of the access service to the presence state.
La présente invention vient améliorer la situation. A cet effet, la présente invention vise tout d'abord un procédé de gestion de l'accès d'un terminal d'utilisateur, connecté à un réseau de communication, au statut d'une ressource physique et/ou logicielle gérée par un gestionnaire. Ce procédé comprend les étapes, mises en oeuvre par le gestionnaire, de : 2 0 détermination d'au moins une propriété relative au terminal ; établissement d'une règle de gestion de l'accès du terminal au statut de la ressource à partir de la propriété déterminée. Ainsi, l'invention permet une prise en compte des propriétés, par exemple de connectivité, du terminal d'utilisateur lors de la gestion de l'accès du terminal au statut de la 25 ressource souhaitée. Dans une réalisation, le procédé comprend une étape de réception par le gestionnaire d'une requête d'accès du terminal à la ressource, ladite requête comprenant des informations relatives au terminal, et une étape de détermination de propriétés utilisant ces informations. Ainsi, l'étape de détermination est précédée d'une étape de réception par le 3 0 gestionnaire précité d'une requête d'accès du terminal au statut de la ressource, cette requête comprenant des informations relatives au terminal et l'étape de détermination précitée utilise les informations relatives au terminal comprises dans la requête d'accès pour déterminer la propriété précitée relative au terminal. A titre d'exemple de réalisation, dans le cadre du protocole SIP, le gestionnaire 35 d'accès reçoit une requête « SIP SUBSCRIBE ». Cette requête comprend des entêtes SIP contenant des informations relatives au terminal. Par exemple, l'entête «P-Access-Network-Info » transporte des informations relatives au réseau d'accès du terminal et l'entête «User-Agent» contient des informations sur le type de terminal. Ces informations permettent de déterminer des propriétés relatives au terminal et ainsi de définir un type de terminal à partir de ces informations. Par exemple, lorsque l'entête «P-Access-Network-Info» indique un accès de type xDSL, le gestionnaire en déduit que le terminal est un terminal de type fixe ayant une connexion stable. Dans une réalisation où le protocole SIP est utilisé, l'étape de réception précitée peut avantageusement être suivie par une étape de conservation d'un contexte de souscription SIP et, en cas d'échec de l'acquittement lorsque la connexion du terminal est instable, le procédé peut alors comprendre une étape de conservation du contexte de souscription SIP pendant une durée déterminée, permettant ainsi notamment la répétition de l'envoi de la notification dont l'acquittement est en échec et/ou l'envoi de nouvelles notifications. Dans une autre réalisation, l'étape de détermination utilise des informations relatives au terminal préalablement stockées dans le gestionnaire. Tel est le cas par exemple lorsque les données concernant le type de terminal sont provisionnées préalablement dans le gestionnaire lors de l'abonnement de l'utilisateur auprès de l'opérateur de télécommunications. Avantageusement, la propriété déterminée par le gestionnaire peut être relative à la stabilité de la connexion du terminal au réseau de communication. Ainsi, lorsque le type de terminal est fixe, la connexion du terminal est considérée 2 0 stable. Dans le cadre de l'accès à un état de présence d'un autre utilisateur, la règle de gestion d'accès établie alors par le gestionnaire peut être alors de supprimer le contexte suite à un échec lors de la réception de l'acquittement de la requête « SIP NOTIFY » ou de conserver ce contexte jusqu'à atteindre un seuil de nombre d'erreurs prédéfini préalablement. En effet, cet échec peut être dû dans ce cas au fait que le terminal de l'utilisateur soit éteint sans avoir effectué au préalable 25 de demande spécifique de fermeture de contexte. Il est donc inutile de continuer à lui envoyer des notifications relatives à l'état de présence. Lorsque le type de terminal est mobile, la connexion du terminal est considérée instable. Dans le cadre de l'accès à un état de présence d'un autre utilisateur, la règle de gestion d'accès établie alors par le gestionnaire, suite à un échec lors de la réception de l'acquittement de 3 0 la requête « SIP NOTIFY », peut être alors de conserver le contexte pendant une durée déterminée par exemple en déclenchant un compteur de durée (« timer »). En effet, cet échec peut être dû au fait que le terminal de l'utilisateur a perdu momentanément la connexion au réseau. Il est donc utile de continuer à lui envoyer pendant une certaine durée des notifications relatives à l'état de présence. Si, pendant cette durée, une autre requête « SIP NOTIFY » est acquittée correctement, le 35 gestionnaire arrête le compteur de durée et le contexte retourne à un état normal. Si après l'échéance du compteur de durée, une autre requête « SIP NOTIFY » n'est pas acquittée correctement, le contexte est supprimé. Un autre exemple concerne le cas dans lequel l'entête «User-Agent» indique que le type du terminal est un téléphone intelligent par exemple de type « iphone 3.0 »®. La connexion du terminal est alors considérée comme fantôme étant donné que l'exécution de la souscription en permanence sur le terminal n'est pas garantie. Dans le cadre de l'accès à un état de présence d'un autre utilisateur, la règle de gestion d'accès établie alors par le gestionnaire, suite à un échec lors de la réception de l'acquittement de la requête «SIP NOTIFY », peut être alors de supprimer le contexte. On indique de manière générale que le statut précité de la ressource peut être avantageusement (mais non limitativement) un état de présence d'un utilisateur de cette ressource. Toutes les variantes du procédé décrites ci-dessus peuvent être présentes isolément ou selon toutes les combinaisons techniquement possibles. L'invention vise aussi un système de gestion de l'accès d'un terminal d'utilisateur, connecté à un réseau de communication, au statut d'une ressource physique et/ou logicielle du réseau, comprenant un gestionnaire de la ressource, le gestionnaire comprenant en particulier : des moyens de détermination d'au moins une propriété relative au terminal ; des moyens d'établissement d'une règle de gestion de l'accès du terminal à la ressource à partir de la propriété déterminée. La présente invention vise aussi le gestionnaire précité en tant que tel, apte à gérer 2 0 l'accès d'un terminal d'utilisateur au statut d'une ressource physique et/ou logicielle, et comprenant en particulier des moyens de détermination d'au moins une propriété relative au terminal ; des moyens d'établissement d'une règle de gestion de l'accès du terminal à la ressource à partir de la propriété déterminée. 25 La présente invention vise aussi un programme d'ordinateur apte à être mis en oeuvre par un gestionnaire d'une ressource physique et/ou logicielle, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de gestion d'accès précité. A titre d'exemple, la figure 2 commentée ci-après peut correspondre à un organigramme représentant l'algorithme général d'un tel programme. 3 0 D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels : - la figure 1 est un schéma synoptique illustrant la structure d'un système de gestion selon un mode de réalisation de l'invention ; la figure 2 est un organigramme illustrant le fonctionnement d'un procédé de gestion selon 35 un mode de réalisation de l'invention. Le mode de réalisation décrit en référence aux figures 1 et 2 est relatif à la gestion de l'accès d'un terminal d'utilisateur (« Watcher ») à l'état de présence d'un autre utilisateur (« Presentity »). L'invention ne se limite cependant pas à ce cas et peut concerner la gestion de l'accès à l'état de toute ressource physique ou logicielle utilisant une souscription SIP. The present invention improves the situation. For this purpose, the present invention aims first of all at a method of managing the access of a user terminal, connected to a communication network, to the status of a physical and / or software resource managed by a manager. . This method comprises the steps, implemented by the manager, of: determining at least one property relating to the terminal; establishing a management rule for the access of the terminal to the status of the resource from the determined property. Thus, the invention makes it possible to take into account the properties, for example of connectivity, of the user terminal when managing the access of the terminal to the status of the desired resource. In one embodiment, the method comprises a step of the manager receiving an access request from the terminal to the resource, said request comprising information relating to the terminal, and a step of determining properties using this information. Thus, the determination step is preceded by a step of reception by the aforementioned manager of a terminal access request to the status of the resource, this request comprising information relating to the terminal and the determination step. above uses the terminal information included in the access request to determine the aforementioned property relating to the terminal. As an exemplary embodiment, in the context of the SIP protocol, the access manager receives a request "SIP SUBSCRIBE". This request includes SIP headers containing terminal information. For example, the header "P-Access-Network-Info" carries information relating to the access network of the terminal and the header "User-Agent" contains information on the type of terminal. This information makes it possible to determine properties relating to the terminal and thus to define a type of terminal from this information. For example, when the header "P-Access-Network-Info" indicates an access of type xDSL, the manager deduces that the terminal is a terminal of fixed type having a stable connection. In an embodiment where the SIP protocol is used, the aforementioned reception step can advantageously be followed by a step of preserving a SIP subscription context and, in the event of failure of the acknowledgment when the connection of the terminal is unstable. , the method may then comprise a step of preserving the SIP subscription context for a determined period of time, thus enabling the repetition of the sending of the notification whose acknowledgment has failed and / or the sending of new notifications. In another embodiment, the determination step uses information relating to the terminal previously stored in the manager. This is the case, for example, when the data concerning the type of terminal is previously provisioned in the manager when the user subscribes to the telecommunications operator. Advantageously, the property determined by the manager may relate to the stability of the connection of the terminal to the communication network. Thus, when the terminal type is fixed, the connection of the terminal is considered stable. In the context of the access to a state of presence of another user, the access management rule then established by the manager can then be to delete the context following a failure when receiving the acknowledgment of the "SIP NOTIFY" request or to keep this context until reaching a predefined number of errors threshold. In fact, this failure may be due in this case to the fact that the user's terminal is turned off without first having made a specific request for closing the context. It is therefore useless to continue to send him notifications concerning the state of presence. When the type of terminal is mobile, the connection of the terminal is considered unstable. In the context of the access to a state of presence of another user, the access management rule then established by the manager, following a failure upon receipt of the acknowledgment of 30 the request "SIP NOTIFY ", can then be to keep the context for a determined duration for example by triggering a timer (" timer "). Indeed, this failure may be due to the fact that the terminal of the user has momentarily lost the connection to the network. It is therefore useful to continue to send him for a certain period of time notifications about the state of presence. If, during this time, another "SIP NOTIFY" request is acknowledged correctly, the handler stops the time counter and the context returns to a normal state. If after the expiration of the time counter, another "SIP NOTIFY" request is not acknowledged correctly, the context is deleted. Another example relates to the case in which the header "User-Agent" indicates that the type of the terminal is a smartphone for example of the type "iphone 3.0" ®. The connection of the terminal is considered ghost since the execution of the subscription permanently on the terminal is not guaranteed. As part of the access to a state of presence of another user, the access management rule then established by the manager, following a failure when receiving the acknowledgment of the request "SIP NOTIFY" , then can delete the context. It is generally indicated that the aforementioned status of the resource can be advantageously (but not exclusively) a state of presence of a user of this resource. All the variants of the process described above may be present in isolation or in any technically possible combination. The invention also aims at a system for managing the access of a user terminal, connected to a communication network, to the status of a physical and / or software resource of the network, comprising a resource manager, the manager comprising in particular: means for determining at least one property relating to the terminal; means for establishing a terminal access management rule for the resource from the determined property. The present invention also aims at the aforementioned manager as such, able to manage the access of a user terminal to the status of a physical and / or software resource, and including in particular means for determining the at least one property relating to the terminal; means for establishing a terminal access management rule for the resource from the determined property. The present invention is also directed to a computer program adapted to be implemented by a manager of a physical and / or software resource, the program comprising code instructions which, when the program is executed by a processor, carry out the steps of the aforementioned access management method. By way of example, FIG. 2 commented below can correspond to a flowchart representing the general algorithm of such a program. Other features and advantages of the invention will become apparent upon examination of the following detailed description, and the accompanying drawings, in which: FIG. 1 is a block diagram illustrating the structure of a management system according to an embodiment of the invention; Fig. 2 is a flowchart illustrating the operation of a management method according to one embodiment of the invention. The embodiment described with reference to FIGS. 1 and 2 relates to the management of the access of a user terminal ("Watcher") to the presence state of another user ("Presentity"). The invention is however not limited to this case and may concern the management of access to the state of any physical or software resource using a SIP subscription.
La figure 1 représente un système comprenant des terminaux d'utilisateurs 2, 4, 6 associés respectivement à des utilisateurs 8, 10, 12. Ces terminaux 2, 4, 6 communiquent entre eux au travers d'un réseau de communication 14 géré par un gestionnaire de réseau 16. Ce gestionnaire 16 est typiquement un serveur de l'opérateur de télécommunications auprès duquel sont abonnés les utilisateurs 8, 10, 12. FIG. 1 represents a system comprising user terminals 2, 4, 6 associated respectively with users 8, 10, 12. These terminals 2, 4, 6 communicate with each other through a communication network 14 managed by a user. network manager 16. This manager 16 is typically a server of the telecommunications operator with which the users 8, 10, 12 subscribe.
Dans l'exemple de réalisation considéré, l'utilisateur 8 a souscrit un abonnement auprès de l'opérateur de télécommunications afin de pouvoir accéder aux états de présence des utilisateurs 10 et 12 qui font partie de ses contacts. A titre d'exemple, l'accès du terminal 2 de l'utilisateur 8 au statut du terminal 4 associé à l'utilisateur 10 est géré par le gestionnaire 16 selon la procédure décrite en référence à l'organigramme de la figure 2. A l'étape 18, le gestionnaire 16 reçoit du terminal 2 une requête de souscription à l'état de présence de l'utilisateur 10. Dans le cadre du protocole SIP, cette requête est une requête «SIP SUBSCRIBE ». Cette requête « SIP SUBSCRIBE » comprend des informations relatives au type du 2 0 terminal 2 et au réseau d'accès du terminal 2. Plus particulièrement, les informations relatives au terminal 2 sont contenues dans un entête «User-Agent» et les informations relatives au réseau d'accès sont contenues dans un entête «P-Access-Network-Info ». A l'étape 20, le gestionnaire 16 vérifie que l'utilisateur 8 a bien les droits pour cette souscription, par exemple en vérifiant que cet utilisateur est abonné au service d'accès aux états de 25 présence d'autres utilisateurs auprès de son opérateur. Il détermine alors, à l'étape 22, une propriété relative à la stabilité de la connexion du terminal 2 au réseau de communication 14 à partir, notamment, des informations concernant le type du terminal 2 et le type d'accès du terminal 2 contenues dans la requête « SIP SUBSCRIBE » reçue à l'étape 18. 3 0 En variante, le gestionnaire 16 dispose de ces informations préalablement à la demande de souscription de l'utilisateur 8, par exemple grâce à une affectation statique d'un type de terminal et/ou d'accès lors de l'abonnement de l'utilisateur 8 auprès de son opérateur. A titre d'illustration, si le terminal 2 est connecté sur un accès xDSL, le type de ce terminal est considéré comme étant fixe. Le gestionnaire 16 en déduit que la connexion du terminal 2 est 35 stable. A l'inverse, si le terminal 2 est connecté sur un accès mobile, le type de ce terminal est considéré comme étant mobile. Le gestionnaire 16 en déduit que la connexion du terminal 2 est instable. Si le terminal 2 est du type à système d'exploitation (ou « operating system ») mono-tâche, comme par exemple 1'« iphone 3.0 »®, l'exécution de l'application d'accès à l'état de présence d'autres utilisateurs en permanence sur le terminal 2 n'est pas garantie. Le gestionnaire 16 en déduit que la connexion du terminal 2 est de type fantôme. A l'étape 24, le gestionnaire 16 conserve un contexte de souscription du terminal 2, comprenant la propriété relative à la stabilité de la connexion définie à l'étape 22, de sorte que, à chaque modification de l'état de présence du terminal 4 ainsi qu'à chaque rafraîchissement de la souscription, le gestionnaire 16 envoie à l'étape 26 une notification au terminal 2 sous la forme d'une requête « SIP NOTIFY ». La suite de l'organigramme de la figure 2 concerne le cas où le terminal 2 n'acquitte pas la requête « SIP NOTIFY ». A l'étape 28, le gestionnaire 16 constate l'échec de l'acquittement. In the exemplary embodiment considered, the user 8 has subscribed to the telecommunications operator in order to access the states of presence of the users 10 and 12 that are part of his contacts. By way of example, the access of the terminal 2 of the user 8 to the status of the terminal 4 associated with the user 10 is managed by the manager 16 according to the procedure described with reference to the flowchart of FIG. step 18, the manager 16 receives from the terminal 2 a subscription request to the state of presence of the user 10. In the context of the SIP protocol, this request is a request "SIP SUBSCRIBE". This request "SIP SUBSCRIBE" includes information relating to the type of the terminal 2 and the access network of the terminal 2. More particularly, the information relating to the terminal 2 is contained in a "User-Agent" header and the information relating to to the access network are contained in a header "P-Access-Network-Info". In step 20, the manager 16 verifies that the user 8 has the rights for this subscription, for example by verifying that this user is subscribed to the access service to the states of presence of other users with his operator . It then determines, in step 22, a property relating to the stability of the connection of the terminal 2 to the communication network 14 from, in particular, information concerning the type of the terminal 2 and the type of access of the terminal 2 contained in the request "SIP SUBSCRIBE" received in step 18. In a variant, the manager 16 has this information prior to the subscription request from the user 8, for example by virtue of a static assignment of a type of user. terminal and / or access during the subscription of the user 8 to its operator. As an illustration, if the terminal 2 is connected to an xDSL access, the type of this terminal is considered to be fixed. The manager 16 deduces that the connection of the terminal 2 is stable. Conversely, if the terminal 2 is connected to a mobile access, the type of this terminal is considered to be mobile. The manager 16 deduces that the connection of the terminal 2 is unstable. If the terminal 2 is of the operating system type (or "operating system") single-task, such as 1 "iphone 3.0" ®, the execution of the application access to the state of presence other users permanently on the terminal 2 is not guaranteed. The manager 16 deduces that the connection of the terminal 2 is of the ghost type. In step 24, the manager 16 retains a subscription context of the terminal 2, comprising the property relating to the stability of the connection defined in step 22, so that, at each modification of the presence state of the terminal 4 and each refresh of the subscription, the manager 16 sends in step 26 a notification to the terminal 2 in the form of a request "SIP NOTIFY". The remainder of the flowchart of FIG. 2 concerns the case where the terminal 2 does not acknowledge the request "SIP NOTIFY". In step 28, the manager 16 recognizes the failure of the acknowledgment.
A l'étape 30, le gestionnaire 16, en fonction de la propriété relative à la stabilité de la connexion déterminée à l'étape 22, décide de la manière de traiter l'échec de l'acquittement de la requête « SIP NOTIFY ». Ainsi, lorsque la connexion est stable, le gestionnaire 16 supprime le contexte. En variante, le gestionnaire 16 conserve le contexte jusqu'à atteindre un nombre d'erreurs 2 0 d'acquittement défini préalablement. Lorsque la connexion est instable, le gestionnaire 16 conserve le contexte pendant une durée déterminée en déclenchant un compteur de durée. Si, pendant cette durée, une autre requête « SIP NOTIFY » est acquittée correctement, le gestionnaire 16 supprime le compteur. Sinon, dans le cas où une autre requête « SIP NOTIFY» n'est pas acquittée correctement après l'échéance du 25 compteur de durée, le gestionnaire 16 supprime le contexte. Lorsque la connexion est de type fantôme, le gestionnaire 16 supprime le contexte. Bien que le mode de réalisation décrite en référence à la figure 2 concerne le traitement de l'échec de l'acquittement de la notification, l'invention n'est pas limitée à ce cas. L'invention s'applique en effet avantageusement à plusieurs types d'opérations en 3 0 lien avec le cycle de vie d'une souscription SIP. Par exemple, le gestionnaire 16 peut établir une règle selon laquelle le terminal 2 doit mettre à jour sa souscription en envoyant la requête « SIP SUBSCRIBE » plus ou moins régulièrement selon la stabilité de sa connexion. Ainsi, dans le cas d'une connexion fixe, le terminal 2 peut se contenter d'envoyer cette requête toutes les quelques heures alors que dans le 35 cas d'une connexion mobile, le terminal 2 doit envoyer cette requête toutes les quelques minutes pour assurer la continuité du service d'accès à l'état de présence. In step 30, the manager 16, as a function of the property relating to the stability of the connection determined in step 22, decides how to deal with the failure of the acknowledgment of the "SIP NOTIFY" request. Thus, when the connection is stable, the manager 16 deletes the context. In a variant, the manager 16 retains the context until a number of previously defined acknowledgment errors are reached. When the connection is unstable, the manager 16 keeps the context for a determined duration by triggering a duration counter. If, during this time, another request "SIP NOTIFY" is correctly acknowledged, the manager 16 deletes the counter. Otherwise, in the case where another request "SIP NOTIFY" is not acknowledged correctly after the expiration of the duration counter, the manager 16 deletes the context. When the connection is of the ghost type, the manager 16 deletes the context. Although the embodiment described with reference to FIG. 2 concerns the treatment of the failure of the acknowledgment of the notification, the invention is not limited to this case. The invention applies in fact advantageously to several types of operations in connection with the life cycle of a SIP subscription. For example, the manager 16 can establish a rule according to which the terminal 2 must update its subscription by sending the request "SIP SUBSCRIBE" more or less regularly according to the stability of its connection. Thus, in the case of a fixed connection, the terminal 2 can simply send this request every few hours whereas in the case of a mobile connection, the terminal 2 must send this request every few minutes for to ensure the continuity of the service of access to the state of presence.
Un autre exemple concerne le contenu de la notification « SIP NOTIFY ». Pour un terminal 2 de type PC, le gestionnaire 16 décide avantageusement d'envoyer un lien vidéo associé au profil de l'utilisateur 10 dans cette notification, étant donné que l'utilisateur 8 a la possibilité d'accéder au contenu d'un tel lien avec son terminal. Par contre, pour un terminal 2 de type téléphone mobile, le gestionnaire 16 décide avantageusement d'envoyer uniquement la photo et la phrase d'humeur associées au profil de l'utilisateur 10 dans la notification. L'invention s'applique également de manière avantageuse à la gestion d'accès au statut d'une ressource logicielle, par exemple, une application de messagerie. Ainsi, lorsque le gestionnaire envoie une alerte au terminal lui indiquant la réception d'un nouveau message et que le terminal n'acquitte pas ce message, le gestionnaire décide selon les propriétés de stabilité de la connexion du terminal, de continuer d'envoyer de nouvelles alertes pendant une certaine durée ou de ne plus en envoyer. L'invention permet ainsi d'améliorer l'expérience utilisateur des services relatifs à l'accès au statut d'une ressource physique et/ou logicielle proposés par l'opérateur de télécommunications. Another example concerns the content of the "SIP NOTIFY" notification. For a PC type terminal 2, the manager 16 advantageously decides to send a video link associated with the profile of the user 10 in this notification, since the user 8 has the possibility to access the content of such a link. link with his terminal. On the other hand, for a terminal 2 of the mobile phone type, the manager 16 advantageously decides to send only the photo and the mood phrase associated with the profile of the user 10 in the notification. The invention also advantageously applies to access management to the status of a software resource, for example, a messaging application. Thus, when the manager sends an alert to the terminal indicating the receipt of a new message and the terminal does not acknowledge this message, the manager decides according to the stability properties of the terminal connection, continue to send the message. new alerts for a certain period of time or no longer send them. The invention thus makes it possible to improve the user experience of the services relating to access to the status of a physical and / or software resource proposed by the telecommunications operator.