Locating Touch Tones in a Capture (VoIP Deployment)

One of the challenges of VoIP is handling DTMF tones. They’re used all the time, but they aren’t really the ideal candidate for VoIP transmission. So, they come with their own set of complications.
Of the two types of DTMF transmissions currently promoted by the VoIP community, only the out-of-band RFC2833 DTMF tones are easy to find with Wireshark. You have the option to listen to in-band DTMF in the audio portion of a call with the player to confirm the receipt and transmission, but this option is available only if you use uncompressed codecs.
The RFC2833 tones are more mechanical. They aren’t a tone at all, simply an event notification that your VoIP phone system reads to play the tone. Figure 11-5, which shows a multi-leg VoIP call, also shows another feature of
the graph — its ability to identify RFC2833 DTMF events. The graph identifies a long list of RTP Num packets associated with the number 5 being sent. Viewing every RTP event packet sent with RFC2833 is a simple way to validate the transmission or receipt of DTMF packets, but you may need to drill down on the individual packets to really see what’s happening to the tones.
The easiest way to sort out the RFC2833 DTMF packets is with a filter. A filter removes all the SIP and SDP packets, so you can’t see when the DTMF packets begin in the flow of things, but the filter does allow you to focus on the DTMF events themselves.
Type the following code into the window in the Filter toolbar:

You know you’ve typed in the filter correctly when the background of the window on the Filter bar turns light green. The background of the filter area toggles from red to green, depending on whether the digits in the window match a valid filter. Don’t forget the space before the exclamation point and the other before the final zero, or the filter will fail, and you won’t get a list of your DTMF packets!
Figure 11-7 shows DTMF digits displayed by using the preceding filter. You need to pay close attention to three things on RFC 2833 DTMF events:

Sequence Number: Located in the RTP section of the capture. It should cascade up while other DTMF events are generated.
Event Duration: Located in the RFC 2833 section of the capture. This represents the duration of time the specific DTMF digit has been transmitted. Just like the sequence number in the RTP section, the value in the Event Duration field should increase with each additional RTP event for the same DTMF digit.
End Notifications: Listed in the summary as DTMF Five 5 (end) in Figure 11-7. RFC 2833 specifies that there should be three end notifications for every RFC2833-transmitted DTMF digit. Figure 11-7 matches the specification, so it includes everything you’d expect. The only difference on the end notification of the DTMF event verses a normal DTMF event sent is that the RFC 2833 section of the packet lists True instead of False in this section of the code:

Packets arriving out of sequence can be confusing for SIP. If one of the last packets of a DTMF digit arrives late because of route flap, jitter, or any other reason, it can cause some problems within your VoIP phone system. Ensure that your hardware is discarding out-of-sequence packets; your SIP server could perceive a DTMF end notification followed by a late arrival as a second unique digit. Instead of discarding the packet and understanding the transmission as 5, the wayward DTMF packet could make your

phone system read the transmission as 55. Reviewing the capture with Wireshark can very easily decipher this situation because the sequence number and event duration validate that the DTMF 5 packet that arrived late was a continuation of the original 5 DTMF digit and not a new transmission of the same digit.

Figure 11-7:
A DTMF capture.
If you need to view the DTMF event in context of the entire call, select a row in the Summary section and click the Clear button on the Filter toolbar. The selected packet in the Summary section remains in the same position in the Summary window, but all the other packets are now available to you, as well. So, you can place the DTMF packet in the context of the call or the flow of traffic on the LAN.