IP Troubleshooting Using Packet Captures
The best way to troubleshoot the IP portion of a fax/modem/text call is with a packet capture. Packet captures provide an unbiased, third-party view of what is occurring on the IP network. In addition, you can observe not only the incoming media stream, but also the outgoing one to ensure that the gateway is properly transmitting packets as it should.
NOTE Although there is an abundance of packet-capturing software available, the easiest to acquire and use is probably Wireshark. The Wireshark software is used for the examples in this book and is available as a free download from http://www.wireshark.org/.
When troubleshooting the IP network with packet captures, it is best to grab a capture at each of the gateways. With captures on both sides, you can view the packets being transmitted from one gateway and then see how those packets arrive at the other gateway and vice versa. Be aware that in Unified CM environments, obtaining a packet capture at the Unified CM server itself shows only the call control signaling because the media stream occurs just between the voice gateways themselves. Therefore, unless you are troubleshooting just a call control signaling issue, it is best to obtain packet captures at each voice gateway because the media stream can be captured and the call control signaling. Figure 12-8 illustrates the placement of packet capture devices for voice gateways in a Unified CM environment.
Figure 12-8 Proper Insertion Points for Packet Capture Devices
Unified CM
Figure 12-8 Proper Insertion Points for Packet Capture Devices
Unified CM
Ideally, simultaneous captures should be made for the same call, but this will require two capture devices, one at each voice gateway. You should also insert the packet capture devices as close as possible to the voice gateway's interface that is used for the origination and termination of the IP connection. In addition, it is sometimes helpful to gather DSP statistics for this call, too, to confirm that the voice gateway's counters are matching up with the trace from the packet capture software.
For modem and fax calls whose media stream uses an RTP encapsulation, Wireshark offers an RTP stream analysis feature for quickly analyzing the bidirectional RTP streams. The fax and modem transport methods that use RTP for encapsulation include modem passthrough, fax pass-through, and Cisco fax relay. Because modem relay uses SPRT and T.38 fax relay uses UDPTL rather than RTP, these transport methods usually have to be analyzed manually. Figure 12-9 highlights the RTP analysis feature in Wireshark for a modem passthrough call.
Figure 12-9 Wireshark RTP Stream Analysis Feature for a Modem Passthrough Call
Wireshark: RTP Stream Analysis
Forward Direction
Reversed Direction |
Analyàig stream From 1.1.1.2 port 17086 to 1.1.1.1 port 19124 S5RC = 527761666
Max delta - 0.021313 sec at packet no. 3971
Total RTP packets = 1817 (expected 1817) Lost RTP packets = 0 (0.00%) Sequence errors = 0
Wireshark: RTP Stream Analysis
Forward Direction
Reversed Direction |
Analyàig stream From 1.1.1.2 port 17086 to 1.1.1.1 port 19124 S5RC = 527761666
|
Packet - | Sequence |
| Delta (ms) |
| litter (ms) |
| lPBW(kbjB) |
| Marker | Status | |
|
|
I4H |
y/ir |
ITS |
1.52 |
81.bU |
[UkJ |
|
1466 |
9756 |
21.07 |
1.19 |
31.60 |
[Ok] |
|
1466 |
«59 |
21.112 |
1.16 |
81.60 |
[OH] |
|
1470 |
9760 |
21.04 |
1.43 |
31.60 |
[Ok] |
|
1472 |
9761 |
17.54 |
1.50 |
SI. 60 |
[Ok] |
|
1471 |
9762 |
21.04 |
1.17 |
31.60 |
[Ok] |
|
1476 |
9763 |
21.04 |
1.14 |
81.60 |
[Ok] |
|
1478 |
9764 |
17,51 |
1.51 |
81.60 |
[Ok] |
|
1460 |
9765 |
21.04 |
1.46 |
31.60 |
[Ok] |
|
14B2 |
9766 |
21.11 |
1.45 |
80, DO |
[Ok] |
|
1464 |
9767 |
21.01 |
1.13 |
31.60 |
[Ok] |
|
I486 |
9768 |
17,51 |
1.19 |
81,60 |
[Ok] |
|
1463 |
9769 |
21.05 |
1.17 |
31.60 |
[Ok] |
|
I4SD |
9770 |
21,01 |
1.11 |
81,60 |
[Ok] |
|
1492 |
9771 |
17.55 |
1.50 |
31.6D |
[Ok] |
|
1494 |
9772 |
21.05 |
1.17 |
81.60 |
[Ok] |
|
1496 |
9773 |
21.08 |
1.15 |
80.00 |
[Ok] |
|
1498 |
9774 |
17.S5 |
1.5t |
80.00 |
[Ok] |
|
1500 |
9775 |
21.04 |
1.46 |
30.00 |
[Ok] |
|
1502 |
9776 |
21.04 |
1.15 |
80.00 |
[Ok] |
|
1804 |
9777 |
21.03 |
1.13 |
80.00 |
[Ok] |
|
1506 |
9776 |
17.51 |
1.49 |
BO. 00 |
[Ok] |
|
1508 |
9779 |
21.04 |
1.17 |
SO. DO |
[Ok] |
|
1510 |
9780 |
21.05 |
1.14 |
31.60 |
[Ok] |
|
1812 |
9781 |
17,52 |
1.51 |
81,50 |
[Ok] |
|
1514 |
9782 |
21.05 |
1.46 |
31.60 |
[Ok] |
|
1816 |
9783 |
21,06 |
1.15 |
81,60 |
[Ok! |
|
1519 |
9784 |
17.54 |
1.51 |
31.60 |
[Ok] |
|
1520 |
9785 |
21.05 |
_1.48 |
81.60 |
rôti II |
Max delta - 0.021313 sec at packet no. 3971
Total RTP packets = 1817 (expected 1817) Lost RTP packets = 0 (0.00%) Sequence errors = 0
Savepayload.,, lump to
Stase
Savepayload.,,
lump to
Stase
The RTP stream analysis feature in Wireshark can be activated by first highlighting a single RTP packet from the media stream that you are interested in viewing. Then, under the Statistics menu at the top, select RTP, and then Stream Analysis.
From the RTP analysis screen shot in Figure 12-9, you will notice how you can quickly check items such as jitter, lost packets, and out-of-sequence packets. The Jitter (ms) column displays the jitter between each packet, and the Delta (ms) column provides the exact amount of time between packets. By default, Cisco IOS voice gateways send G.711 passthrough packets every 20 ms, and you can see how this value is reasonably close to the delta times in Figure 12-9.
A Sequence column displays the RTP sequence number. This allows you to confirm that there are not any missing or out-of-order packets.
At the top of the screen capture, the direction of the stream, including the originating and terminating IP addresses and UDP port numbers, is provided. At the bottom of the window, the maximum delta (Max delta) is shown along with totals for lost RTP packets and sequence errors.
There is a tab for Reversed Direction in the upper-left corner of the window. This allows you to quickly view the RTP media stream and its statistical information for the opposite direction.
Clicking the Graph button in Figure 12-9 takes the statistical information about the RTP stream and produces a graphical display of the data. This allows a quick visual analysis of the RTP media stream. Figure 12-10 illustrates the graphical representation of the data in Figure 12-9.
Figure 12-10 Graphical Display from the Wireshark RTP Stream Analysis Feature
Figure 12-10 Graphical Display from the Wireshark RTP Stream Analysis Feature
As expected, the graph in Figure 12-10 does not show any problems, but it shows you how the RTP media stream can be broken down graphically. Options such as the axis intervals and stream selection are even present to customize certain aspects of the graph.
However, for transport methods such as T.38 fax relay and modem relay that do not rely on an RTP encapsulation, the RTP stream analysis feature does not work. Instead, an approach that involves more manual work must be used. Figure 12-11 shows a T.38 fax relay call in Wireshark.
TIP Modem passthrough with the redundancy option enabled tends to cause corrupted statistics when viewed with Wireshark's RTP stream analysis feature. Therefore, it is recommended that you disable redundancy on modem passthrough if you are trying to analyze the RTP media stream with Wireshark.
Figure 12-11 Wireshark Packet Capture of a T.38 Fax Relay
|
El« |
5it Mm Qpbjn ■•--■v.:- J ytlp |
||
|
Si |
* # « at & a ^ ». a |
3 "i> (t 2 |
HQ ^Si^Q el 0 n St H |
|
[If, |
| [udp. port == 17736) f,i, (udp.port == 17930) |
* | Expression,,, | cjtat | fippip1 |
J Enter « dtsplay filer, or choose cnccf rot* recently used ¡ilftcss, Itwbad'giound color of tfte fieW e dunged by a ■ J continuous syntax check (or win Is vakl, rod k Irr/aW).
1.1.1.1 1.1.1.2 T.38 1.1.1.1 1.1.1.2 T.38 1.1.1.1 1.1,1.2 T.38 1.1.1.1 1.1.1.2 T.38 1.1.1.1 1.1.1.2 T.38 1.1.1.1 1.1.1.2 T.38 1.1,1.1 1.1.1.2 T, 38 1.1.1.1 1.1,1.2 T.38 1.1.1.1 1.1.1.2 T.38 1.1.1.1 1.1.1.2 T.38 1.1.1.1 1.1.1.2 T.38 1.1,1.1 1.1,1.2 T*38 1.1,1,1 1.1,1.2 T.38
701 0.031593
702 0.028108
703 0.021053
704 0.031690
705 0.038656
706 0.010S68
707 0.011337
1.1.1.1 1.1.1.1 1.1.1.1 1.1.1.1 1.1.1.1 1.1.1.1 1.1,1.2
UUP. ULiPJLPHLPei U-Sia.UAl. IIU H."U8L8 LWJ
udp: UDPTLPacket Seq-00050 data:tf21: hdlc-data[04]
udp: UDPTLPacket seq-00051 data:v21: hdlc-data[04]
UDP: UDPTLPacket Seq-QC052 data;v21: hdlc-data[04]
udp: UDPTLPacket Seq-OCOS3 data;u21: hdlc-data[04]
udp: UDPTLPacket seq-00054 data:t/21: hdlc-data[04]
udp: UDPTLPacket seq-00055 cfaia:v2l: hdlc-data[04]
udp: UDPTLPacket 5eq-QC0S6 data:v21: hdlc-data[04]
udp: UDPTLPacket Seq-00057 <Jata;v21: hdlc-data[04]
udp: UDPTLPacket seq-00058 data:v21: hdlc-data[04] hdlc-fcs-OK Chdlc Reassemb'
udp: UDPTLPacket Seq-00058 data:tf21: hdlc-data[04] hdlc-fcs-OK (hdlC Reassert udp: UDPTLPacket seq-00Q59 daia:v21: hdlc-data [ff]
udp: UDPTLPacket Seq-00060 daxa:y?l: hdlc-data[CS]
udp: UDPTLPacket Seq-00061 data:v21: hdlc-data[01]
udp; UDPTLPacket seq-00062 data:v21: hdlc-data udp: UDPTLPacket seq-QCQ64 data:v21: hdlc-data[15]
udp: UDPTLPacket seq-QCQ65 <Jata;v21: hdlc-data[01]
udp: UDPTLPacket seq-00066 data:v21: hdlc-data[01]
udp: UDPTLPacket Seq-00067 data:v21: hdlc-data[88] hdlc-fcs-OK Chdlc Reassemtf udp: UDPTLPacket seq-00068 data:v2i: hdlc-s1g-end udp: UDPTLPacket seq-Qtl069 t301nd: no-signal UDP: UDPTLPacket Seq-QOOQO tJOlnd: no-signal
a Frame 700 (64 bytes on vrlre, 64 bytes captured)
e Ethernet nt src: cisco_52;d3:di (00:0d;ed:52:d3:dl), ost: cisco_47:35:a9 C00;17i95:47j35:a9) E internet Protocol, Src: 1.1.1.1 (1.1.1.ID. Dst: 1.1.1.2 Cl.1.1.23 H User Datagram Protocol, Src Port: 17930 (17930), Dst Port: 17796 (17796) b itu-t Recommendation T.3B
a [Stream setup by H245 Cframe 598)] p UDPTLPacket sequence number: 63 B IFPPacket
Error recovery: secondary-1fp-packets (0)
0000 00 17 95 47 35 a9 00 Od ooio oo 27 14 ca oo oo fe 11
0020 01 02 45 oa 45 84 00 13
0030 00 00 73 00 00 00 00 00
"TgT7
Fte:"C^Cuxunsris ¿nd 5rttln^\Adrtrt^*w\C^iopli>^rf-ca^ures\t38-pcciocci-h323"2£MKB |P: 21MD: 1981 M: 0
In Figure 12-11, the UDPTL sequence numbers are easily visible. However, you must manually look through the capture to find missing or out-of-order packets. This same manual searching procedure applies for detecting jitter, too. When searching for excessive jitter, make sure the Time Display Format is set to Seconds Since Previous Packet under the View menu.
Manually parsing through a long packet capture can be quite tedious. Hopefully, you will have some idea of where in the call the problem begins from a time perspective. If so, you can narrow down the portion of the packet capture with the problem. When looking at the capture, remember that you need to confirm that packets are arriving at evenly spaced time intervals and in sequence without any missing sequence numbers.
Post a comment