La transaction SIP a été annulée, souvent après un CANCEL.
Où peut-elle apparaître ?
Cette erreur peut apparaître dans les journaux applicatifs, messages clients, outils de supervision ou traces de protocole. Conservez l’horodatage, le contexte de la requête et les événements autour avant de dépanner.
Causes probables
Appel raccroché avant réponse
Forking SIP
Timeout amont
Vérifications et résolution
Rechercher le CANCEL dans la trace
Vérifier qui initie l’annulation
Comparer les timestamps SIP
Précaution : 487 est souvent une conséquence normale et non la cause racine.
Lecture diagnostique et validation
Pour « 487 — Requête SIP annulée », capturez au minimum le Call-ID, l’heure, le code SIP final, les en-têtes From/To/Via/Contact et, lorsqu’il est présent, le SDP. Cette trace permet de distinguer une décision du trunk, du PBX, du terminal ou d’un équipement de bordure.
Test discriminant
Reproduisez un appel court et comparez le dialogue SIP des deux côtés du trunk. Vérifiez l’étape exacte où apparaît la réponse, les codecs et paramètres SDP négociés, ainsi que les temporisations et routes. Une capture réseau ou le log de signalisation doit confirmer le même Call-ID de bout en bout.
Critère de résolution
Le correctif est validé lorsque le scénario d’appel initial aboutit avec la réponse attendue et que l’échange SIP reste cohérent sur plusieurs essais. Contrôlez aussi un appel entrant ou sortant comparable pour vérifier que la modification n’a pas déplacé le problème vers une autre route ou un autre codec.