Résumé

  • RFC 3326 permet à une requête SIP de transporter la raison de son émission, sous forme de cause SIP ou Q.850 issue de l’interfonctionnement téléphonique.
  • Le champ ne modifie pas le traitement SIP : CANCEL annule toujours, tandis que Reason peut indiquer qu’une autre branche a répondu.

Une branche a répondu ; les autres devaient encore s’arrêter

Un proxy envoie un INVITE vers plusieurs branches. L’une répond 200 OK. Les autres téléphones peuvent pourtant continuer à sonner. Le proxy leur envoie donc CANCEL. C’est la méthode SIP qui met fin à l’alerte, et non un champ qui en raconte la raison.

RFC 3326, publié en décembre 2002, donne au proxy un moyen d’ajouter cette explication : Reason: SIP;cause=200;text="Call completed elsewhere". Un service peut distinguer un appel pris sur une autre branche d’un appel abandonné avant réponse. Cela peut compter pour un journal d’appels manqués ou une interface, alors que l’action protocolaire immédiate reste identique.

La séparation est le choix de conception essentiel. SIP disposait déjà de codes d’état pour les réponses. Mais une même requête peut être envoyée pour des motifs différents, et la requête ne transporte pas nécessairement la réponse qui l’a déclenchée. Reason rattache une cause à la requête qui agit en conséquence. C’est une métadonnée explicative, pas un second canal de commande.

Chaque cause a son espace de référence

RFC 3326 qualifie les valeurs par protocole. SIP signifie que le paramètre cause contient un code d’état SIP ; Q.850 indique une cause décimale du plan de signalisation téléphonique de l’UIT-T. Une passerelle peut ainsi préserver une cause de libération du réseau téléphonique dans un message SIP. Le nombre seul ne suffit pas : le nom du protocole identifie le système de numérotation.

Le paramètre text est utile aux humains, mais ne fait pas autorité pour le traitement. La cause provient du vocabulaire du protocole indiqué ; la méthode, le statut et le contexte transactionnel restent portés par le message lui-même. Lire cause=200 comme une réponse, ou une valeur Q.850 comme un statut SIP, confond deux surfaces de contrôle.

Le champ ne garantit pas non plus une compréhension universelle. RFC 3326 autorise les implémentations à ignorer les valeurs qu’elles ne connaissent pas et précise que Reason n’a aucun effet sur le traitement protocolaire. La requête suit les règles SIP même si le destinataire jette l’explication. L’extension peut donc aider les services sans devenir une condition cachée de l’état d’appel.

Une réponse masquée par le fork

Le document relie aussi Reason au problème des réponses d’erreur hétérogènes en présence de fork. Un INVITE peut recevoir des échecs finaux différents selon les branches. Le proxy attend généralement les résultats avant de décider quoi remonter ; une erreur utile peut ainsi rester masquée tandis qu’une autre branche demeure active. RFC 3326 évoque l’encapsulation d’un statut final dans une réponse provisoire comme un usage possible de Reason.

Cette formulation est importante : il s’agit d’un mécanisme candidat, pas d’une preuve que chaque fork révèle toutes les erreurs ou qu’un service déployé résout le problème. Le champ transporte une cause ; il ne définit ni une politique universelle de classement des échecs ni un remplacement du traitement des réponses SIP.

Les évolutions ont préservé la distinction

RFC 8606 a ensuite ajouté un paramètre de localisation ISUP aux causes Q.850 pour préserver, lorsque l’information existe, le lieu d’origine d’une libération. RFC 9366 a ensuite assoupli la règle d’une seule valeur par protocole uniquement lorsque le protocole enregistré définit le sens de plusieurs valeurs. Dans les deux cas, la structure précise la provenance ; elle ne transforme pas Reason en opération.

C’est une distinction historique utile. RFC 3087 examinait le Request-URI comme contexte local de sélection d’un service ; RFC 3326 rattache une cause à une action SIP déjà choisie. L’un sélectionne une destination de requête ; l’autre explique son émission. Aucun ne prouve l’authentification, l’autorisation, l’historique complet de l’appel ou le résultat en aval.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3326.html
  2. https://www.rfc-editor.org/info/rfc3326/
  3. https://www.rfc-editor.org/rfc/rfc3261.html
  4. https://www.rfc-editor.org/rfc/rfc9366.html
  5. https://www.rfc-editor.org/rfc/rfc8606.html
  6. https://www.rfc-editor.org/rfc/rfc5411.html
  7. https://www.rfc-editor.org/rfc/rfc4411.html