April 24, 2012 • 3 min read
First off, thanks to everyone who sent in a solution. The solution is posted here, or try the challenge yourself below!
Unlike past challenges, this challenge involves multiple capture files with two SIP clients attempting a VoIP call behind a SIP aware router. The first capture was taken on the LAN side of the router. The second capture was taken on the WAN side of the router.
https://www.cloudshark.org/analysis/a7b1b8057a33/voip_flow
Right away you see the first SIP client (192.168.0.101) initiates a SIP INVITE. Next, the second SIP client (192.168.1.102) sends an INVITE. From the call flow, you can see the first client gets a response and goes on to complete a call. The second client simply sends a CANCEL a few seconds later. So what happened to client #2’s SIP INVITE? Why no response?
The SIP call flow on the WAN only shows 2 IPv4 endpoints since all the VoIP calls flow through NAT. But the SIP call flow only shows 1 call. One way to find out what happened is to take the SIP Call-ID from the LAN and use it as a display filter on the WAN. Using the LAN side SIP Call flow, we see the failed called has a SIP Call-ID of 136a84693f3-2@host2.cdrouter.com. You can enter ‘sip.Call-ID == “136a84693f3-2@host2.cdrouter.com”’ to display all the SIP packets from this call on the WAN.
Based on this result, we see the original SIP INVITE from client 2 is never seen on the WAN. The packet appears to have been dropped between the LAN and WAN capture points. There’s your solution – packet loss on the router.
Until next time!
We recently showcased a case study with TalkFree. TalkFree is a great example of a VoIP provider who uses CloudShark’s VoIP packet decoding and analysis to troubleshoot their network more effectively than using traditional analysis tools.
CloudShark’s VoIP troubleshooting tools are one of its more robust features. This week, we wanted to provide a packet challenge that would give you a taste of VoIP troubleshooting using CloudShark - as such, our packet capture challenge deals with VoIP calls.
If you can answer the question below, send an email to info@cloudshark.org with your address and Tee-Shirt size, we’ll send out a CloudShark tee shirt to the first 10 correct responses we receive.
In this challenge, there are 2 capture files provided. One capture was taken on the LAN side of a router. The other capture was taken on the WAN side of a router. On the LAN side, 2 SIP clients attempt to start a VoIP call. If you look at the WAN side, you only see a single VoIP call. What happened? Why don’t we see 2 calls on the WAN and why weren’t both calls successful? Be specific!
Some more detail: The router is performing NAT on the IPv4 connections from the LAN to WAN. However, the router also has a SIP ALG that should be translating all embedded IPv4 addresses between the LAN and the WAN. The router’s WAN address is 192.168.200.2. On the LAN side, VoIP client #1 is at 192.168.0.101 and VoIP client #2 is at 192.168.0.102.
We’ve also placed some annotations inside of the LAN side capture to help you get started.
LAN capture: https://www.cloudshark.org/captures/42e9711a1d3d
WAN capture: https://www.cloudshark.org/captures/159b72f0dd79
LAN SIP Call Flow: https://www.cloudshark.org/analysis/a7b1b8057a33/voip_flow
WAN SIP Call Flow: https://www.cloudshark.org/analysis/10a9010e5e68/voip_flow
Good Luck and Happy Packet Surfing!
