Lire le diagramme en échelle SIP

À quoi cela sert

Le diagramme en échelle SIP présente la signalisation d'un appel sous forme d'une suite de flèches entre les pairs concernés. Vous le trouvez dans l'onglet Call flow du diagnostic d'appel et dans l'onglet Call flow de l'analyse d'appels. Les deux utilisent le même diagramme. Pour les appels Teams passant par le SBC intégré, il existe un diagramme en échelle distinct à deux voies, qui se lit de la même manière.

Ce chapitre explique la structure du diagramme et montre, à l'aide de six flux typiques, quels messages vous voyez et dans quel ordre. Grâce à ces modèles, vous repérez rapidement, dans un flux inconnu, l'endroit où il s'écarte du cas normal.

SIP fonctionne avec des requêtes et des réponses. Une requête porte une méthode telle que INVITE ou BYE. Chaque réponse porte un code à trois chiffres : 1xx est provisoire, 2xx un succès, 3xx une redirection, 4xx à 6xx une erreur. Un appel se compose d'au moins un dialogue, reconnaissable au Call-ID commun. Le CUCM se trouve entre les participants et tient un dialogue distinct avec chaque côté. Un appel de téléphone à téléphone montre donc deux dialogues.

Prérequis

• Un diagnostic d'appel terminé ou un appel disposant d'un flux d'appel dans l'analyse d'appels. Rôle ROLE_APP_CALL_DIAGNOSTICS.
• Sur le CUCM, Cisco CallManager utilise le niveau de trace Detailed avec Enable SIP Call Processing Trace. Sinon, les traces ne contiennent aucun message SIP.
• Le diagramme montre uniquement le SIP. Les téléphones SCCP, les ports analogiques et les passerelles MGCP ou H.323 n'apparaissent pas comme une voie à part.
• Pour les messages CUBE : capture de débogage activée sur le CUBE et accès en lecture aux CUBE.

Pas à pas : comment procéder

1. Lisez d'abord la ligne d'en-tête des voies. Déterminez quelle voie est l'appelant, laquelle est le nœud CUCM et laquelle est la destination ou le trunk.
2. Recherchez le premier INVITE. Il se trouve tout en haut et va de l'appelant au CUCM.
3. Suivez le dialogue de l'appelant vers le bas jusqu'à la dernière réponse à cet INVITE. Sa couleur vous indique comment l'appel s'est terminé : vert pour un appel répondu, rouge pour un échec.
4. Recherchez l'INVITE que le CUCM envoie à la destination. Comparez pour savoir si l'erreur vient de la destination ou si le CUCM l'a générée lui-même.
5. Utilisez Hide 100 Trying et Hide NOTIFY, INFO and OPTIONS pour masquer ce qui n'a pas d'importance.
6. Utilisez les boutons de dialogue pour désactiver des dialogues un à un, jusqu'à ce que seul le segment que vous examinez soit visible.
7. Cliquez sur le message décisif et lisez les en-têtes et le SDP dans la vue du message.
8. Observez les écarts dans la colonne de l'heure. Une longue pause avant une réponse montre où quelque chose était en attente.
9. Comparez le flux avec les modèles des sections suivantes.

Champs et options : structure du diagramme

Flux : appel abouti

1. INVITE avec SDP de l'appelant vers le CUCM. L'appelant propose ses codecs.
2. 100 Trying en retour vers l'appelant. Le CUCM a accepté la requête.
3. INVITE du CUCM vers la destination. Il s'agit d'un nouveau dialogue, d'une autre couleur.
4. 180 Ringing de la destination vers le CUCM, puis du CUCM vers l'appelant. La destination sonne.
5. 200 OK avec SDP de la destination. L'appelé a décroché et indique son codec.
6. ACK dans les deux dialogues. L'établissement de l'appel est confirmé et l'audio circule.
7. BYE du côté qui raccroche, et 200 OK en confirmation. Dans l'analyse d'appels, le résultat est Answered.

Flux : occupé

1. INVITE de l'appelant vers le CUCM, 100 Trying en retour.
2. INVITE du CUCM vers la destination.
3. 486 Busy Here de la destination, en rouge. Plus rarement 600 Busy Everywhere.
4. ACK du CUCM vers la destination. Toute réponse finale à un INVITE est acquittée par un ACK.
5. 486 Busy Here du CUCM vers l'appelant, puis ACK de l'appelant. Résultat Busy, cause Q.850 17.
6. Si le 486 n'apparaît que dans le dialogue avec l'appelant et qu'il n'y a aucun INVITE vers la destination, le CUCM a décidé lui-même, par exemple parce que le seuil d'occupation (busy trigger) de la ligne est atteint.

Flux : injoignable ou sans réponse

1. INVITE de l'appelant vers le CUCM, 100 Trying en retour.
2. Numéro inconnu : 404 Not Found directement du CUCM, sans INVITE vers une destination. De même 410 Gone, 484 Address Incomplete, 485 Ambiguous ou 604 Does Not Exist Anywhere. Résultat Unreachable.
3. Destination non enregistrée ou temporairement indisponible : 480 Temporarily Unavailable. Résultat No answer.
4. La destination ne répond pas : après 180 Ringing, rien ne suit pendant longtemps, puis 408 Request Timeout ou 480. La colonne de l'heure montre le temps d'attente.
5. Trunk ou passerelle en défaut : 503 Service Unavailable ou 502 Bad Gateway depuis la voie du trunk. Résultat Failed.
6. Les codecs ne concordent pas : 488 Not Acceptable Here. Comparez le SDP de l'INVITE avec les codecs pris en charge par la destination.
7. La destination refuse : 403 Forbidden ou 603 Decline. Résultat Rejected.

Flux : abandon par l'appelant

1. INVITE de l'appelant, 100 Trying, INVITE vers la destination, 180 Ringing.
2. CANCEL de l'appelant vers le CUCM. L'appelant raccroche avant que quelqu'un ne décroche.
3. 200 OK en réponse au CANCEL.
4. CANCEL du CUCM vers la destination, puis son 200 OK.
5. 487 Request Terminated en réponse à l'INVITE d'origine, dans les deux dialogues, chacun avec un ACK.
6. Le 487 est rouge bien qu'il n'y ait aucune erreur. Ce qui compte, c'est le CANCEL qui le précède. Résultat Abandoned by caller.

Flux : redirection

1. INVITE de l'appelant vers le CUCM.
2. Avec un renvoi d'appel dans le CUCM, l'INVITE ne va pas vers la destination composée, mais vers la destination du renvoi. Il porte un en-tête Diversion avec le numéro composé à l'origine et le motif.
3. Avec un renvoi sur non-réponse, vous voyez d'abord INVITE et 180 Ringing vers la première destination, puis CANCEL vers cette destination et un nouvel INVITE avec Diversion vers la seconde.
4. Si un pair redirige de lui-même, il répond par 302 Moved Temporarily, en orange. L'en-tête Contact indique la nouvelle destination. Un nouvel INVITE vers celle-ci suit.
5. La suite du flux est la même que pour l'appel abouti. Dans l'analyse d'appels, l'appel porte la caractéristique Forwarded, et l'onglet Overview affiche la Redirect chain.
6. Cliquez sur l'INVITE vers la destination du renvoi et lisez l'en-tête Diversion pour connaître l'origine et le motif.

Flux : transfert

1. Le premier appel est établi comme dans le flux de l'appel abouti.
2. La personne qui transfère met l'appel en attente : un nouvel INVITE dans le dialogue existant (re-INVITE) avec SDP, auquel répondent 200 OK et ACK.
3. La personne qui transfère établit un appel de consultation vers la cible du transfert : un nouveau dialogue avec INVITE, 180 Ringing, 200 OK, ACK.
4. REFER de la personne qui transfère vers le CUCM. L'en-tête Refer-To indique la cible du transfert, accompagné de Replaces pour un transfert avec consultation.
5. 202 Accepted en réponse au REFER, puis NOTIFY avec la progression.
6. Le CUCM relie l'appelant et la cible du transfert par un re-INVITE ou un UPDATE et un nouveau SDP dans les deux dialogues.
7. BYE vers la personne qui transfère. Les deux dialogues restants se poursuivent. Dans l'analyse d'appels, l'appel porte la caractéristique Transfer.

Contrôler le résultat et circonscrire les erreurs

• Vous avez compris le flux lorsque vous pouvez dire en une phrase qui a mis fin à l'appel et avec quel message.
• 401 Unauthorized ou 407 Proxy Authentication Required juste après le premier INVITE, suivi d'un ACK et d'un second INVITE avec le même Call-ID, constitue l'authentification normale du terminal et non une erreur.
• Le diagramme ne commence pas par INVITE : les traces du CUCM n'ont commencé qu'après le début de l'appel. L'avis au-dessus du diagramme l'indique.
• Le diagramme se termine sans BYE : l'appel était encore en cours lors de la lecture des traces, ou la limite de 800 messages a été atteinte.
• Un segment manque entièrement : le terminal n'utilise pas SIP, un nœud n'a pas pu être lu, ou l'appel est passé par un nœud situé au-delà de la limite de 8 nœuds. Vérifiez le tableau des nœuds.
• Les deux participants se trouvent sur la même voie : ils partagent une adresse IP. Distinguez-les à l'aide des boutons de dialogue.
• 200 OK et ACK sont présents, mais il n'y avait pas d'audio : la signalisation est correcte. Comparez l'adresse, le port et le codec dans le SDP des deux côtés et vérifiez le chemin média dans le réseau.
• Les identifiants de connexion et les clés SRTP sont supprimés dans la vue du message. Les messages très longs sont tronqués à 8 Ko.