Résumé

  • La valeur terminated de la RFC 6665 est décisive pour le cycle de vie de l’abonnement, pas pour celui de toute ressource suivie.
  • timeout, deactivated, rejected, giveup, invariant et noresource n’annoncent pas le même avenir ; seule la dernière raison affirme que l’état de ressource surveillé n’existe plus.
  • Un dossier fiable sépare l’abonnement, le corps d’état défini par le paquet d’événements, la transaction NOTIFY, l’interprétation applicative et l’action humaine ou automatique.

La fin de l’observation n’est pas la fin de l’objet

Les interfaces aiment les adjectifs sans complément. « Terminé » devient alors la propriété de la ligne entière : appel terminé, terminal disparu, compte fermé. Dans Subscription-State, le complément est pourtant explicite. Le client doit considérer l’abonnement comme terminé. Cette certitude est réelle et immédiatement exploitable.

La ressource suit une autre grammaire. La RFC 6665 fournit un cadre SIP, puis confie à chaque paquet d’événements la définition des données d’état, de l’état neutre et, le cas échéant, de la différence entre vue complète et mise à jour partielle. Le cadre n’unifie pas une présence, une boîte vocale, un appel et une ressource métier sous une même valeur terminale.

Confondre les deux plans rend une panne d’observation indiscernable d’une disparition. Un abonnement peut expirer alors que la ressource continue. La ressource peut aussi cesser d’exister avant que le dernier message atteigne l’abonné. La couleur d’un tableau de bord ne réconcilie pas ces chronologies.

Le code de raison dessine la suite

La liste de la RFC 6665 ressemble moins à un vocabulaire d’échec qu’à un aiguillage. Avec deactivated, le client devrait se réabonner immédiatement ; la migration entre nœuds notificateurs en est un usage central. probation demande d’attendre. rejected signale un changement de politique d’autorisation et déconseille une nouvelle tentative. timeout correspond à l’absence de rafraîchissement avant l’échéance et permet de recommencer. giveup indique que le notificateur n’a pas obtenu l’autorisation à temps.

Deux valeurs interdisent en principe un nouvel abonnement pour des motifs opposés. noresource affirme que l’état de ressource surveillé n’existe plus. invariant affirme qu’il ne changera pas dans un avenir prévisible. Traduire les deux par « ressource terminée » détruit précisément l’information que le protocole a conservée.

Une raison absente ou inconnue ne vaut pas noresource. Elle laisse une incertitude et permet éventuellement une nouvelle tentative, en respectant retry-after. Un paramètre expires ne doit pas servir de preuve de remplacement : avec terminated, il n’a aucune sémantique et le destinataire doit l’ignorer.

Le dernier NOTIFY peut ne rien dire de la dernière valeur

Pour se désabonner, le client envoie SUBSCRIBE avec Expires: 0. Le notificateur produit alors un NOTIFY final. La RFC avertit que ce message peut contenir un état de la ressource ou ne pas en contenir. Un traitement conforme doit accepter les deux cas.

L’absence de corps ne constitue donc pas une valeur nulle de la ressource. Elle signifie qu’aucune valeur finale n’est fournie dans cette pièce. Si un corps existe, son type de média, les règles du paquet, son caractère complet ou partiel et ses éventuels numéros de version restent déterminants. Le mot terminated ne peut pas attribuer rétroactivement un sens universel au contenu.

La réponse 200 au NOTIFY possède elle aussi une portée précise. Elle indique que le message a été jugé acceptable par l’abonné SIP. Le client ne doit pas prolonger la transaction dans l’attente d’un utilisateur. Le 200 est donc un reçu de traitement automatique, et non la preuve qu’un opérateur a lu l’alerte, compris l’état ou exécuté une procédure.

Le premier événement peut précéder la réponse

La confirmation effective de la création vient du premier NOTIFY. Une réponse 2xx au SUBSCRIBE annonce que l’abonnement a été accepté et qu’un NOTIFY sera envoyé immédiatement. À cause du réordonnancement, des pertes ou du fork, ce NOTIFY peut néanmoins arriver avant la fin de la transaction SUBSCRIBE. Avant sa réception, la ressource reste dans l’état neutre défini par le paquet.

Il faut donc conserver plusieurs horloges. La transaction mesure demandes et réponses. L’abonnement mesure création, rafraîchissement et expiration. La ressource mesure les changements définis par son paquet. L’observateur ajoute l’heure de collecte, de parsing et d’affichage. Le dernier horodatage visible n’est pas nécessairement le dernier fait autorisé.

Une preuve exploitable associe identifiant local, Call-ID, tags, valeur Event, cible, CSeq du NOTIFY, état exact, raison, délai, source et résultat d’authentification. Dans une pièce distincte figurent la présence du corps, son empreinte, son type, la version du paquet et du parseur, ainsi que la valeur applicative produite.

Un usage disparaît sans emporter le dialogue

La RFC 6665 décrit l’abonnement comme un état applicatif associé à un dialogue. La RFC 5057 de Robert Sparks montre que plusieurs usages d’un même dialogue ont des cycles de vie indépendants. Lors d’un transfert, un usage d’invitation peut continuer après la fin de l’usage d’abonnement. Dire « dialogue terminé » ou « appel terminé » à partir du seul en-tête reproduit la confusion à un niveau supérieur.

Les clarifications ultérieures ont resserré l’adressage. La RFC 7621 impose l’usage de GRUU dans les contextes concernés pour atteindre l’instance d’agent utilisateur voulue. La RFC 7647, cosignée par Sparks et Roach, traite les abonnements implicites créés par REFER et déconseille la réutilisation problématique des dialogues. Elles aident à identifier l’usage et son point de contrôle ; elles ne changent pas le sujet grammatical de terminated.

Une contribution ne certifie pas un déploiement

Adam Roach est l’unique auteur nommé des RFC 3265 et 6665, la seconde remplaçant la première en juillet 2012. Son profil IETF actuel mentionne une participation depuis 1998, un mandat d’Area Director Applications and Real-Time de 2017 à 2020 et d’anciennes présidences de XCON, SIPCORE et NETVC. La page recense aujourd’hui 23 RFC et aucune fonction active au 22 avril 2026.

Cette provenance éclaire la norme, pas les choix d’un fournisseur. Le libellé commercial, les temporisations, la politique d’autorisation et la décision métier d’un système restent sous la responsabilité de ses opérateurs. Le nom de Roach ne transforme pas leur interprétation en résultat de protocole.

Cinq reçus plutôt qu’un état rouge

Le premier reçu nomme l’abonnement : dialogue, événement, cible et clé locale. Le deuxième décrit son cycle : état, raison, durée et heure. Le troisième conserve la ressource : corps présent ou absent, empreinte, version du paquet et résultat du parseur. Le quatrième couvre la garde de transport : notificateur, authentification, transaction et réponse. Le cinquième attribue la décision : attendre, migrer, se réabonner, alerter ou clôturer.

Cette séparation améliore l’automatisation. timeout peut ouvrir une alerte de perte de visibilité. deactivated peut rester incomplet jusqu’au premier NOTIFY du successeur. noresource peut demander une confirmation applicative avant une action irréversible. Une raison manquante peut enfin être affichée comme inconnue, sans fiction.

Sources