Résumé

  • RFC 3680 sépare l’état d’inscription d’une adresse-of-record de sa liste de contacts. Sans aucun contact enregistré, l’adresse conserve l’état défini init.
  • Les notifications peuvent ne contenir que les contacts modifiés. L’abonné doit les appliquer dans l’ordre des versions et demander une resynchronisation complète après une lacune ; cela ne prouve ni présence humaine, ni terminal actif, ni appel abouti.

Une réponse sans contact n’était pas une absence de réponse. Dans le modèle de RFC 3680, une adresse-of-record (AoR) sans inscription gardait un état : init. L’état appartenait à l’adresse, tandis que chaque contact disposait de sa propre machine d’état, créée à l’inscription et supprimée avec le contact.

Publié en mars 2004, RFC 3680 introduit l’événement SIP reg. Un abonné autorisé envoyait SUBSCRIBE et recevait des informations au format application/reginfo+xml. La notification initiale pouvait présenter l’état complet ; les suivantes ne contenaient souvent que les changements. Chaque document indiquait s’il était full ou partial et portait une version, initialisée à zéro puis incrémentée d’une unité pour chaque document de cette souscription.

Cette économie de données avait une contrepartie : un delta n’énumère pas ce qui n’a pas changé. L’abonné devait donc maintenir sa propre table et fusionner les documents dans l’ordre. Il traitait la version suivante ; il rejetait une version plus ancienne. S’il constatait un saut, RFC 3680 lui recommandait de renouveler sa souscription afin de provoquer une notification complète. Sans cette récupération, une table locale pouvait sembler cohérente tout en ayant perdu un changement.

L’état de l’AoR éclaire le cas limite. L’arrivée du premier contact faisait passer l’adresse de init à active. Elle restait active tant qu’un contact subsistait. Lorsque le dernier expirait ou était retiré, l’AoR passait par terminated avant de revenir immédiatement à init ; ce dernier passage ne devait jamais figurer dans un NOTIFY. La fin du contact pouvait, elle, être notifiée. Le contact disparaissait donc sans que l’adresse cesse d’avoir un état interprétable.

« Active » reste un fait d’inscription, pas une disponibilité personnelle. Cela ne prouve ni qu’un utilisateur est présent, ni qu’un terminal fonctionne à cet instant, ni qu’un appel aboutira. RFC 3856 définit séparément la présence SIP : les inscriptions peuvent alimenter un service de présence, mais les deux notions ne se substituent pas l’une à l’autre. Et la spécification ne démontre pas qu’une implémentation réelle respecte ses règles.

La contribution de RFC 3680 tient à cette frontière : rendre les changements observables par des abonnés autorisés, préserver un état pour l’ensemble vide, et prévoir un retour à l’état complet après une notification manquée. La bonne question n’est donc pas seulement « reste-t-il un contact ? », mais aussi « quelle version fonde cette vue et qu’autorise-t-elle réellement à conclure ? »

Sources