Résumé

  • Dans RFC 4028, seul un 2xx à un re-INVITE ou UPDATE de rafraîchissement repousse l’expiration de la session SIP. Une tentative, un 422 ou la simple présence de trafic de signalisation ne suffisent pas.
  • Session-Expires, Min-SE et refresher répartissent des contraintes de délai et une obligation de maintenance ; ils ne constatent ni l’arrivée du média, ni la présence humaine, ni le droit de facturer.
  • L’exploitation fiable conserve séparément la transaction, le dialogue, le média, l’application et la décision commerciale, puis rapproche ces preuves avant d’affirmer qu’un appel continue ou se termine.

Deux états verts qui ne racontent pas la même chose

Imaginons un opérateur de voix gérée. Le proxy reste dans le chemin SIP et conserve l’état du dialogue. Le média RTP prend un autre chemin. Au milieu de l’appel, l’extrémité chargée du rafraîchissement envoie un UPDATE sans SDP. La réponse 200 OK arrive, Session-Expires est reconduit et le proxy décale son échéance locale.

Sur le trajet média, une panne vient pourtant de supprimer l’audio dans un sens. Les rapports RTCP se taisent. L’application du combiné continue d’exécuter son automatisme, alors que la personne ne participe plus. Si la facturation lit uniquement l’événement « refresh réussi », elle peut prolonger un service que personne ne reçoit.

La mécanique de RFC 4028 reste correcte. Son objet est plus étroit : éviter que des agents utilisateurs et des proxies avec état conservent indéfiniment les ressources d’une session lorsque BYE manque ou se perd. Le rafraîchissement périodique borne la durée de l’état SIP.

Le texte distingue lui-même cette vitalité de signalisation des indices propres au média, par exemple RTCP pour l’audio. Le temporisateur répond à « l’état SIP peut-il être conservé ? ». Il ne répond pas à « la conversation produit-elle encore un service réel ? ».

Intervalle, minimum et échéance

Trois valeurs sont souvent confondues sous le mot délai.

L’intervalle de session est la durée maximale entre deux rafraîchissements réussis. Sa valeur active vient du Session-Expires du dernier 2xx pertinent.

Le minimum exprime le rythme le plus rapide qu’un élément accepte. Les requêtes en cours de dialogue consomment des ressources ; Min-SE empêche un voisin de réclamer des rafraîchissements arbitrairement fréquents.

L’expiration est une échéance locale. L’UAS la calcule à partir de l’envoi du dernier 2xx, l’UAC à partir de sa réception, et chaque proxy à partir de l’événement qu’il observe. Le transit et le traitement créent plusieurs horloges proches, non un instant mondial certifié.

Le journal d’incident doit donc conserver la réponse qui a installé l’intervalle, les temps d’envoi et de réception, l’identité du rafraîchisseur et le calcul local. Une phrase comme « l’appel expirait à 14 h 05 » masque souvent l’élément qui a produit cette heure.

Le chemin négocie aussi

Le client initial peut annoncer l’option timer et proposer un intervalle. Les proxies qui gardent l’état d’appel peuvent demander le mécanisme, réduire Session-Expires ou relever Min-SE. Ils ne peuvent pas imposer un intervalle inférieur au minimum accumulé. L’UAS arrête la valeur dans la réponse 2xx et y ajoute refresher ; au retour, les proxies observent ce résultat sans le modifier.

Si une valeur proposée est trop courte, un élément renvoie 422 Session Interval Too Small avec son Min-SE. L’UAC peut recommencer dans une nouvelle transaction, avec un CSeq supérieur et le plus grand minimum pertinent appris sur le chemin.

Ce 422 ne prolonge rien. L’ancienne échéance continue. Un 422 tardif peut donc exiger une nouvelle valeur généreuse pour l’avenir tout en laissant très peu de temps pour réussir la transaction présente. Une métrique qui ne garde que le 200 final efface cette période de risque.

La hausse des 422 peut traduire un changement de route, une politique plus stricte, une protection contre la charge, un défaut de configuration ou une tentative de provoquer du trafic. Ces causes ne relèvent pas du même responsable.

Le rafraîchisseur n’est pas le propriétaire

refresher=uac et refresher=uas assignent qui doit envoyer la prochaine requête. UAC et UAS sont les rôles de la transaction courante, pas les identités permanentes de l’appelant et de l’appelé. L’ancien UAS devient UAC lorsqu’il envoie son propre UPDATE.

Un journal qui note seulement uac perd donc la personne technique réellement tenue d’agir. Il faut relier le rôle à l’extrémité, au dialogue, à la méthode, au CSeq et au sens de la requête.

Le fork ajoute une autre séparation. Un INVITE initial peut produire plusieurs dialogues, chacun avec son intervalle, son rafraîchisseur et son expiration, ou sans temporisateur. Le succès d’une branche ne maintient pas les autres.

Enfin, le rôle peut être renégocié. Si le 2xx le plus récent ne contient plus Session-Expires, le mécanisme peut être désactivé en plein dialogue. L’existence historique d’un temporisateur n’est pas une preuve de son existence actuelle.

Seul le 2xx repousse la limite

La règle normative est simple : seul un 2xx à une requête de rafraîchissement étend l’expiration.

L’envoi d’UPDATE, une réponse provisoire, un défi 401 ou 407, un 422, l’écriture réussie sur une connexion ou l’observation de la requête par un proxy ne suffisent pas. Une nouvelle tentative authentifiée pourra réussir ; la première n’aura pas déplacé l’échéance.

Si la transaction expire ou reçoit 408 ou 481, l’UA rafraîchisseur envoie BYE. Face à d’autres erreurs, il peut appliquer une relance bornée, sans recommencer indéfiniment.

L’autre UA, qui attend le rafraîchissement, doit envoyer BYE légèrement avant sa propre expiration s’il n’a rien reçu. RFC 4028 recommande une avance égale au plus petit de 32 secondes et du tiers de l’intervalle. Cette marge tient compte des pare-feu et ALG NAT susceptibles de fermer le passage SIP à l’échéance.

Le proxy a un pouvoir différent. À son expiration, il peut supprimer son état et libérer ses ressources ; il ne doit pas créer BYE. Il gère son registre local, pas la volonté des extrémités.

Ainsi, un proxy peut avoir nettoyé sa mémoire pendant que du média direct circule encore. Un BYE peut partir et se perdre. Les deux extrémités peuvent atteindre leurs limites à des instants légèrement différents. Transformer tout cela en une heure unique de raccrochage fabrique une certitude.

Un UPDATE n’est pas toujours un battement vide

Le rafraîchissement utilise un re-INVITE ou un UPDATE ordinaire. RFC 3311 permet à UPDATE de modifier l’information de session et la cible distante. RFC 3261 place re-INVITE dans les règles du dialogue, de la cible et de l’offre/réponse.

Pour un rafraîchissement pur, RFC 4028 recommande UPDATE sans offre lorsque le pair le comprend. Un re-INVITE transporte normalement une offre, même inchangée. Une requête envoyée pour modifier la session peut aussi rafraîchir le temporisateur.

Le même 2xx peut alors confirmer le délai et accompagner un changement de Contact, une offre SDP, une mise en attente, un changement d’adresse, de codec ou de direction. RFC 6141 traite les collisions, les 491 et la remise en cohérence des re-INVITE précisément parce qu’il ne s’agit pas d’un ping banal.

La télémétrie doit indiquer si la requête était uniquement temporelle, si elle portait SDP, si la version ou les flux ont changé et quelle réponse a clos l’échange.

Le média possède ses propres preuves

RFC 3264 négocie des flux sendonly, recvonly, sendrecv, inactive ou rejetés avec un port zéro. Cette description dit ce que les agents ont accepté, non quels paquets sont arrivés.

RFC 3550 rappelle que RTP ne garantit ni livraison ni qualité. RTCP produit des rapports de réception, de synchronisation et de participation utiles. Il ne prouve toujours pas qu’un humain écoute, consent ou obtient la valeur attendue.

Il faut garder cinq réalités : la transaction SIP ; le dialogue et son temporisateur ; le média RTP/RTCP ; l’application et l’usager ; la règle commerciale ou réglementaire. Le 2xx est une preuve forte dans les deux premières. Il ne traverse pas automatiquement les trois suivantes.

Le média peut mourir tandis que le SIP se rafraîchit. Il peut continuer durant une partition de signalisation. Un flux volontairement inactif peut appartenir à une session valide. Un logiciel peut rafraîchir alors que l’utilisateur est parti.

Dans le vocabulaire de Heng Lu, le registre symbolique reste utile à condition de ne pas absorber la réalité pratique. Les systèmes qui transportent, mesurent, facturent et exécutent gardent leurs responsabilités propres.

Une intégrité par saut, avec une limite

Les proxies modifient légitimement les champs du temporisateur. Une protection S/MIME de bout en bout ne convient donc pas. RFC 4028 recommande TLS sur chaque saut pertinent et SIPS.

Cette intégrité empêche un tiers extérieur de réduire la durée et d’amplifier la charge seulement si le chemin entier est protégé. Elle ne transforme pas Session-Expires en attestation de présence ou de service.

Le registre des errata de RFC 4028 contient des corrections vérifiées de vocabulaire et d’exemple. Il contient aussi des propositions non validées. Un signalement de mai 2026 discute le traitement par un proxy d’un souhait explicite refresher=uas; son statut reste Reported. Il mérite un test d’interopérabilité, pas une présentation comme nouvelle norme.

Une trace capable de résister à la contestation

La trace utile relie Call-ID et tags à l’identité concrète derrière UAC ou UAS. Elle conserve méthode, CSeq, branche, route, champs de temporisation à chaque saut, horaires d’envoi et de réception, échéances calculées et événement 2xx décisif.

Elle note aussi les effets associés : présence et empreinte du SDP, évolution de l’offre/réponse, directions de flux, Contact, défis d’authentification et relances. BYE porte un auteur et une cause : action humaine, panne de rafraîchissement, expiration du pair ou politique applicative.

Les preuves média et commerciales restent indépendantes. Les messages SIP révèlent identité et topologie ; un stockage restreint peut garder l’original tandis que la télémétrie générale utilise des projections ou empreintes.

Les essais doivent couvrir 422 près de l’échéance, 401 puis succès, 408, 481, absence de refresh, nettoyage du proxy sans BYE, média mort avec SIP frais, média vivant après perte SIP, forks aux délais différents, désactivation du timer, UPDATE sans offre, re-INVITE avec SDP modifié, changement de cible, bascule qui perd l’état et saut non protégé.

La sortie n’est pas un voyant « appel actif ». C’est une chronologie qui explique quelle couche est restée vivante et qui avait le droit d’agir.

Sources