Read the SIP ladder diagram

What it is for

The SIP ladder diagram shows the signalling of a call as a sequence of arrows between the peers involved. You find it on the Call flow tab in call diagnostics and on the Call flow tab in call analysis. Both use the same diagram. For Teams calls over the integrated SBC there is a separate ladder diagram with two lanes, which you read in the same way.

This chapter explains the structure of the diagram and uses six typical flows to show which messages you see in which order. With these patterns you quickly recognise in an unfamiliar flow where it deviates from the normal case.

SIP works with requests and responses. A request carries a method such as INVITE or BYE. Every response carries a three-digit code: 1xx is provisional, 2xx success, 3xx redirection, 4xx to 6xx error. A call consists of at least one dialog, recognisable by the shared Call-ID. The CUCM sits between the parties and keeps a separate dialog with each side. A call from phone to phone therefore shows two dialogs.

Prerequisites

• A finished call diagnosis or a call with a call flow from call analysis. Role ROLE_APP_CALL_DIAGNOSTICS.
• On the CUCM, Cisco CallManager uses trace level Detailed with Enable SIP Call Processing Trace. Otherwise the traces contain no SIP messages.
• The diagram shows SIP only. Phones with SCCP, analogue ports and gateways with MGCP or H.323 do not appear as a lane of their own.
• For CUBE messages: debug capture switched on at the CUBE and read access to the CUBEs.

Step by step: how to proceed

1. Read the header row of the lanes first. Determine which lane is the caller, which is the CUCM node and which is the destination or the trunk.
2. Find the first INVITE. It is at the top and goes from the caller to the CUCM.
3. Follow the caller's dialog downwards to the last response to this INVITE. Its colour tells you how the call ended: green answered, red failed.
4. Find the INVITE that the CUCM sends to the destination. Compare whether the error comes from the destination or was generated by the CUCM itself.
5. Use Hide 100 Trying and Hide NOTIFY, INFO and OPTIONS to hide what does not matter.
6. Use the dialog buttons to switch off individual dialogs until only the leg you are examining is visible.
7. Click the decisive message and read the headers and the SDP in the message view.
8. Watch the gaps in the time column. A long pause before a response shows where something was waiting.
9. Compare the flow with the patterns in the following sections.

Fields and options: structure of the diagram

Flow: successful call

1. INVITE with SDP from the caller to the CUCM. The caller offers its codecs.
2. 100 Trying back to the caller. The CUCM has accepted the request.
3. INVITE from the CUCM to the destination. This is a new dialog with a different colour.
4. 180 Ringing from the destination to the CUCM and from the CUCM on to the caller. The destination is ringing.
5. 200 OK with SDP from the destination. The called party has picked up and names its codec.
6. ACK in both dialogs. The call setup is confirmed and the audio flows.
7. BYE from the side that hangs up, and 200 OK as confirmation. In call analysis the result is Answered.

Flow: busy

1. INVITE from the caller to the CUCM, 100 Trying back.
2. INVITE from the CUCM to the destination.
3. 486 Busy Here from the destination, red. Less often 600 Busy Everywhere.
4. ACK from the CUCM to the destination. Every final response to an INVITE is acknowledged with ACK.
5. 486 Busy Here from the CUCM to the caller and the caller's ACK. Result Busy, Q.850 cause 17.
6. If the 486 appears only in the dialog to the caller and there is no INVITE to the destination, the CUCM decided itself, for example because the busy trigger of the line is reached.

Flow: unreachable or not answered

1. INVITE from the caller to the CUCM, 100 Trying back.
2. Number unknown: 404 Not Found directly from the CUCM, without an INVITE to a destination. Likewise 410 Gone, 484 Address Incomplete, 485 Ambiguous or 604 Does Not Exist Anywhere. Result Unreachable.
3. Destination not registered or temporarily unavailable: 480 Temporarily Unavailable. Result No answer.
4. Destination does not respond: after 180 Ringing nothing follows for a long time, then 408 Request Timeout or 480. The time column shows the waiting time.
5. Trunk or gateway faulty: 503 Service Unavailable or 502 Bad Gateway from the lane of the trunk. Result Failed.
6. Codecs do not match: 488 Not Acceptable Here. Compare the SDP in the INVITE with the codecs the destination supports.
7. Destination rejects: 403 Forbidden or 603 Decline. Result Rejected.

Flow: abandoned by the caller

1. INVITE from the caller, 100 Trying, INVITE to the destination, 180 Ringing.
2. CANCEL from the caller to the CUCM. The caller hangs up before anyone picks up.
3. 200 OK to the CANCEL.
4. CANCEL from the CUCM to the destination and its 200 OK.
5. 487 Request Terminated as the response to the original INVITE, in both dialogs, each with ACK.
6. The 487 is red although there is no error. What matters is the CANCEL before it. Result Abandoned by caller.

Flow: redirection

1. INVITE from the caller to the CUCM.
2. With call forwarding in the CUCM, the INVITE does not go to the dialled destination but to the forwarding destination. It carries a Diversion header with the originally dialled number and the reason.
3. With call forwarding on no answer you first see INVITE and 180 Ringing to the first destination, then CANCEL to that destination and a new INVITE with Diversion to the second one.
4. If a peer redirects by itself, it responds with 302 Moved Temporarily, orange. The Contact header names the new destination. A new INVITE to it follows.
5. The rest of the flow is the same as for the successful call. In call analysis the call carries the feature Forwarded, and the Overview tab shows the Redirect chain.
6. Click the INVITE to the forwarding destination and read the Diversion header to see origin and reason.

Flow: transfer

1. The first call is established as in the successful flow.
2. The transferring party puts the call on hold: another INVITE in the existing dialog (re-INVITE) with SDP, answered with 200 OK and ACK.
3. The transferring party sets up a consultation call to the transfer target: a new dialog with INVITE, 180 Ringing, 200 OK, ACK.
4. REFER from the transferring party to the CUCM. The Refer-To header names the transfer target, together with Replaces for a consultative transfer.
5. 202 Accepted to the REFER, then NOTIFY with the progress.
6. The CUCM connects the caller and the transfer target with a re-INVITE or UPDATE and new SDP in both dialogs.
7. BYE to the transferring party. The two remaining dialogs continue. In call analysis the call carries the feature Transfer.

Check the result and narrow down errors

• You have understood the flow when you can say in one sentence who ended the call and with which message.
• 401 Unauthorized or 407 Proxy Authentication Required directly after the first INVITE, followed by ACK and a second INVITE with the same Call-ID, is the normal authentication of the device and not an error.
• The diagram does not start with INVITE: the traces on the CUCM started only after the call began. The notice above the diagram says so.
• The diagram ends without BYE: the call was still in progress when the traces were read, or the limit of 800 messages was reached.
• A leg is missing completely: the device does not use SIP, a node could not be read, or the call went through a node beyond the limit of 8 nodes. Check the table of nodes.
• Both parties are on the same lane: they share an IP address. Tell them apart with the dialog buttons.
• 200 OK and ACK are present, but there was no audio: the signalling is in order. Compare address, port and codec in the SDP of both sides and check the media path in the network.
• Credentials and SRTP keys are removed in the message view. Very long messages are shortened to 8 KB.