SIP arranges a communication session: who is calling, which destination should ring, and when the conversation ends. Work through the small examples below to learn how to read a registration exchange, a successful call and the audio description carried inside a message.
You need basic familiarity with IP addresses and ports. Start with how VoIP separates signaling from audio if those roles are new. All names, addresses and traces here are fictional teaching examples. Message excerpts are abridged and cannot be sent as complete packets.
1. Register an address before following a call
A SIP user agent is an endpoint such as a phone or softphone. A registrar accepts bindings between a user’s SIP address and a contact address. A proxy can use that location information to route a later request. These are logical roles; one service may provide several. The core definitions and message fields are in RFC 3261, the SIP specification.
A fictional registration
Mira’s identity is sip:mira@example.com. Her phone offers sip:mira@192.0.2.10:5060 as its contact. The identity is the address other users know; the contact describes where this endpoint proposes to receive SIP requests.
- The phone sends
REGISTER sip:example.com SIP/2.0with its contact and requested lifetime. - The registrar returns
401 Unauthorizedwith an authentication challenge. - The phone sends another REGISTER containing the calculated authorization response.
- A
200 OKconfirms acceptance. The phone reads the granted binding lifetime and refreshes it before expiry.
A challenge followed by success is a normal authentication exchange. Repeated challenges call for checking the account, realm and supported authentication algorithm. RFC 8760 updates SIP Digest authentication with SHA-256 and SHA-512/256 support; old examples using MD5 should not become a new deployment’s security template. Keep passwords and authorization values out of shared troubleshooting notes.
Registration creates a location binding; the INVITE exchange below requests a conversation. Some service arrangements use preconfigured routes without endpoint registration. Confirm which arrangement your provider expects before diagnosing a missing REGISTER.
2. Read a successful call from top to bottom
In this simplified example Mira calls Leon. The table collapses intermediary proxy hops and omits retransmissions, authentication and early-media variations. RFC 3665’s basic SIP call-flow examples provide longer traces for comparison.
Swipe horizontally, or focus the table and use the arrow keys.
| Step | Direction and message | What to look for |
|---|---|---|
| 1 | Mira → Leon: INVITE with SDP offer | Destination and proposed media parameters. |
| 2 | Toward Mira: 100 Trying | Request processing has begun; this response can come from an intermediary. |
| 3 | Leon → Mira: 180 Ringing | Alerting progress. |
| 4 | Leon → Mira: 200 OK with SDP answer | The INVITE succeeded; inspect accepted media. |
| 5 | Mira → Leon: ACK | Acknowledgment of the successful INVITE response. |
| 6 | Audio packets flow in both directions | Follow the negotiated media endpoints separately. |
| 7 | Mira → Leon: BYE; Leon → Mira: 200 OK | Session termination and its response. |
Match each response to its method. A 200 response to REGISTER means registration succeeded; a 200 response to BYE means termination succeeded. In an actual capture, highlight the request and its replies before deciding what the number proves.
3. Find the fields that connect the trace
This invented INVITE excerpt belongs to step 1. Missing headers, the body and its byte length are deliberately omitted.
INVITE sip:leon@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-lab01
From: Mira <sip:mira@example.com>;tag=mira01
To: Leon <sip:leon@example.com>
Call-ID: lesson-01@192.0.2.10
CSeq: 1 INVITE
Contact: <sip:mira@192.0.2.10:5060>
Content-Type: application/sdpUse Call-ID to group related messages; tags distinguish dialogs within that grouping. CSeq identifies the method and sequence number. Via describes the response path, with its branch identifying a transaction. From and To identify the participants; Contact supplies a target for subsequent requests. A displayed caller identity alone establishes no proof of the caller’s legitimacy. See RFC 3261’s header definitions.
Practice by writing “registration,” “INVITE response,” or “termination response” beside each 200 in your trace. Then inspect its CSeq to check your answer. An SBC may create a separate call leg with different identifiers; correlate its logs when a single Call-ID search stops at that boundary.
4. Decode an SDP offer and answer
SDP, defined in RFC 8866, describes a session. Here are selected lines from Mira’s fictional offer:
c=IN IP4 192.0.2.10
m=audio 40000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecvThe connection address is 192.0.2.10; the proposed audio receive port is 40000. The media uses the RTP/AVP profile and payload type 0, identified as PCMU with an 8,000 Hz clock. sendrecv expresses both sending and receiving. Real SDP also includes required session-level fields omitted here.
Predict the destination
Assume Leon’s answer accepts that format and advertises 198.51.100.20, audio port 41000, and sendrecv. In this deliberately simple direct-media exercise, Mira sends audio toward 198.51.100.20:41000; Leon sends toward 192.0.2.10:40000. Compare your prediction with the actual packets.
The SDP offer/answer model in RFC 3264 explains how peers agree on media and direction. A real deployment can use media relays, NAT traversal and encrypted profiles. Read its negotiated details instead of assuming the SIP server address is the audio destination.
5. Turn the lesson into a troubleshooting exercise
Use an authorized lab capture or your platform’s sanitized diagnostic export. Wireshark’s VoIP Calls window, under Telephony, can show recognized calls and a flow sequence. Encrypted signaling may require endpoint or server diagnostics to expose the message fields.
- Record the call time, time zone, participants and capture location. Identify the relevant call and follow its setup through termination.
- For repeated authentication challenges, compare the challenge and retry. For a 488 response, investigate the offered media and platform logs. For a timeout, locate the last request and the next hop expected to answer.
- For a connected call with one-way sound, compare each advertised media destination with packets observed there. Check the endpoint’s selected microphone and speaker too.
- Write what the evidence establishes and what remains unobserved. Continue with directional packet-loss and jitter analysis when media arrives but sounds poor.
Download the SIP trace exercise and answer key for a reusable observation sheet. The exercise uses documentation addresses and example.com; it is a reading lab, not a production configuration.