Application Note

Using Ethereal to Debug

SIP and RTP on Dialogic ®
Voice over IP (VoIP)
Products
Application Note Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products

Executive Summary
This application note explains how to set up, configure, and use the
Open Source, PC-based network protocol analyzer Ethereal with
Dialogic® voice over Internet Protocol (VoIP) telephony products.
Setting up and using Ethereal in a telephony hardware and software
environment involves some special considerations, which this
application note addresses. This note also serves as a beginning
installation, configuration, and user’s guide for Ethereal with Dialogic
VoIP products. It explores the use of Ethereal in a VoIP test
environment by describing how to get started debugging VoIP protocols
using Ethereal, providing debugging guidelines, and showing examples
of real-world problem scenarios.
Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products Application Note

Table of Contents
About Ethereal........................................................................................................ 2

Test Environment.................................................................................................... 2

Methodology........................................................................................................... 2

Windows® Installation.............................................................................................. 2

Linux Installation .................................................................................................... 2

Openxtra Ethereal Installation ................................................................................. 3

General Setup and Use .......................................................................................... 4

VoIP Problem-Solving ............................................................................................. 5

Troubleshooting Scenarios ...................................................................................... 5

SIP Signaling Working but No Voice................................................................. 5

Packets Lost to Local Loopback Interface ........................................................ 6

Address Changed for Host Media Processing Software Host System ................ 6

rfc2833 Type DTMF Not Working Properly....................................................... 6

Conclusions............................................................................................................ 7

Product List ............................................................................................................ 7

Dialogic Host Media Processing Software System............................................. 7

Dialogic Telephony Hardware-Based System.................................................... 7

Cisco ATA 188 ................................................................................................ 7

Snom 200 ....................................................................................................... 7

Networking Equipment .................................................................................... 7

References ............................................................................................................. 8

Acronyms ............................................................................................................... 8

1
Application Note Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products

About Ethereal Finally, a SIP phone from Snom Technology AG is also

Ethereal is an Open Source, PC-based protocol analyzer included in the test environment.
project providing network analysis features that can help a The SIP endpoints are illustrated in Figure 1.
developer understand the behavior of a VoIP installation.
Ethereal can monitor and collect Transmission Control The communications service framework shown in Figure 1 is
Protocol (TCP) and User Datagram Protocol (UDP) a C++ framework developed at Dialogic. It is used to
packets from a network and sort and display them in an develop communications applications using the Dialogic®
intelligible way. Standard Runtime Library. While this framework is used in
the test environment described in this application note,
Ethereal is widely used by network professionals for developers can also use an application or middleware written
troubleshooting, analysis, software and protocol to the R4 and Global Call APIs instead of this framework.
development, and education. Its Open Source license
allows experts in the networking community to add The example configuration shown in Figure 1 represents a
enhancements. commonly used VoIP application development environment.
However, the configuration also contains several features that
Ethereal runs on many popular computing platforms, may be less obvious to newcomers to Dialogic® telecom
including the Unix, Linux, and Windows® operating solutions or to SIP/RTP. These features will be explained in
systems. the "General Setup and Use" section that follows.
For more information and to download Ethereal, visit
http://www.ethereal.com. Methodology
To debug any SIP/H.323/RTP VoIP problem, you closely
Test Environment monitor the operation of the network. Resolving a
The test environment consists of four different VoIP problem often requires taking an accurate look at all the
components that interoperate with one another. packets involved during the course of a call. You can
purchase expensive "sniffers" that do this based on
Two of the selected VoIP components are based on proprietary hardware, but Ethereal, a freely-available Open
hardware and software products from Dialogic. The first Source product, provides comparable functionality for
Dialogic component is a Dialogic® architecture server identifying most common (and many less common) issues.
running Dialogic® Host Media Processing (HMP)
Software. (To learn more about HMP software, go to Note that although Ethereal is available for many operating
http://www.dialogic.com/products/ip_enabled/hmp_softw systems, this application note describes its use only on the
are.htm.) With HMP software, all Session Initiation Windows and Red Hat Linux operating systems.
Protocol (SIP) signaling, Real Time Protocol (RTP)
streaming, and media processing are handled in host Windows ® Installation
software and the IP session. Voice streaming data is The Windows installation is done by downloading the
transmitted through the host Ethernet Network Interface binary version of Ethereal from
Card (NIC). In addition to SIP, the H.323 protocol is also http://www.ethereal.com/distribution/win32/.
supported by VoIP hardware and software products from
Systems may require version 3.0 or later of the WinPCap
Dialogic, with its functionality exposed via the Global Call
Packet Capture Drivers. Links on the binaries download
API. While SIP is used for the purposes of this paper,
H.323 could also be used in the test environment. page point to the driver download. You should install the
drivers before proceeding with the Ethereal installation
The second Dialogic component is a Dialogic architecture directions. The installation is complete when an Ethereal
server using a Dialogic® telephony board that provides startup icon appears on the desktop of the target system.
embedded RTP streaming and media processing features.

The third component is a Cisco Analog Telephone Adaptor Linux Installation

(ATA) 188 that provides analog to VoIP media gateway Ethereal can be installed on Red Hat Linux using Remote
features and is attached to two common analog phones. Packet Modules (RPMs). Locate the Ethereal version

2
Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products Application Note

Analog Phones
HMP-based SIP Endpoint

IVR Application

Communications Services Ethereal

Framework
Analog
Dialogic Host Media Processing 2-Wire
Software (GlobalCall-based SIP) Connections

Host Ethernet NIC

Cisco ATA
188

SIP Signaling and SIP Signaling and

RTP Streaming RTP Streaming

NetGear DS108 Dual Speed HUB

RTP Streaming SIP Signaling SIP Signaling and

RTP Streaming

Host Ethernet NIC Dialogic

DM/IP240-1T1 SNOM 200
SIP Phone
Vovida Dialogic
SIP Stack System Release
Ethereal Communications Service
Framework

IVR Application

IPLink-based SIP Endpoint

Handset

Figure 1. SIP Endpoints

compatible with the Red Hat Linux version you are using Openxtra Ethereal Installation
(go to http://www.rpmfind.net to locate these and other An extended version of Ethereal, Ethereal-XTRA, is also
RPMs.) There are four packages you must install for the available under GNU Public License from Openxtra at
full GUI-based product. Install them in this order: http://www.openxtra.co.uk/freestuff/ethereal-xtra.php.

Ethereal-XTRA is available only for the Windows

1. Ethereal-base
operating system, with installation based on an
2. Ethereal-gtk+ installation wizard.

3. Ethereal-usermode A useful feature for VoIP work is RTP stream analysis.

Once an RTP stream has been captured, it is possible to
4. Ethereal-kde (or ethereal-gnome, depending on the easily look at relationships between packets. For example,
window manager used) you can peruse delay between packets by scrolling down
the list. If a 20 msec packet size has been specified, you
You can then start the utility by simply typing “ethereal” can note how close to the 20 msec boundary each packet
in a shell. is delivered. Jitter, which is a variation in packet arrival

3
Application Note Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products

Figure 2 .OpenXtra RTP Analysis

time, is calculated for each packet as well. Figure 2 shows We recommend that you plug in all Ethernet connections
an example of RTP stream analysis. into an Ethernet hub, rather than a router. A router has the
intelligence to not waste system resources by forwarding
Note that the two streams — one for each direction —
packets not destined for its address. A hub simply
are shown separately. Another feature makes it possible to
broadcasts all packets to all connected NICs. Access to IP
dump the payloads for either RTP stream into a file so
packets on the system's LAN can be beneficial when using a
that the audio data it is carrying can be heard.
host-based Ethernet monitor such as Ethereal. RTP packets
may be headed for the NIC on the Dialogic telephony
General Setup and Use board, but they need to be caught and displayed on the
You should run Ethereal in "promiscuous mode," system running Ethereal. Even with an Ethernet router,
meaning that it will grab and display any packet that it Ethereal can still be used to monitor the traffic coming in
sees on the Ethernet NIC, not just packets destined for its and out of the Dialogic VoIP system (see Figure 1) to debug
own address. This is important for two reasons: or to troubleshoot problems specific to that particular
system (for example, a connection with no RTP audio).
1. The Dialogic telephony board has its own address
and NIC. (The host NIC is not used for RTP.) The operation of Ethereal is described in an online
manual, which you can download at
2. The RTP (or SIP) packets could be headed
http://www.ethereal.com/docs/user-guide. Here we will
elsewhere, not to the system that you are expecting,
only cover the basics for setting up and using Ethereal to
where Ethereal is running.
get you going as quickly as possible with the utility. For
You can set promiscuous mode in either of two locations: general use, set these display options when a Capture ->
Start is used to begin packet capture:
• In the Edit -> Preferences -> Capture screen
X Update list of packets in real time
• In the Capture -> Start -> Capture options window
that pops up when starting packet capture X Automatic scrolling in live capture

4
Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products Application Note

This allows you to get an idea of what is happening in • Is there a match in the choice of media (given by
real time (although any in-depth analysis must be done Media Attribute) in the Session Description Protocol
after a call is made and the trace stopped). (SDP) portions of the INVITE and OK messages?
Ethereal provides a full set of filters to control collection • Does RTP streaming start after the SIP ACK
or display of protocols. Initially, ensure that the SIP acknowledgement message?
protocol is enabled:
• Are the source and destination addresses for the RTP
Edit -> Protocols -> Enable All packets correct?
Adding “SIP” to the filter text box on the bottom left side • Take a look at the RTP payload type. Does the
of the screen and then selecting the Apply button will payload type match that requested by the call
either suppress collection (pre-capture) or display (post- originator?
capture) of RTP packets. This is desirable due to the
• Look at the RTP payload itself. Does it look like a
number RTP packets generated. You can deactivate
"random" mixture of values that would likely be
filtering by pressing the Reset button.
describing digitized voice? Or is it a more a repetitive
RTP packets are normally displayed simply as UDP. To set of values, such as 0xff, that could indicate silence?
view them as RTP:
• If Ethereal-XTRA is used, listening to the RTP-based
• Select a UDP packet audio may also be useful. To do this:
• Decode by selecting Tools-> Decode As -> Transport o Select a UDP packet
-> RTP -> Apply
o Decode as RTP by selecting: Tools-> Decode As ->
Transport -> RTP -> Apply
VoIP Problem-Solving
In general, approach any VoIP problem by first looking at o Invoke RTP stream analysis by selecting Tools->
the SIP signaling. Only investigate RTP once the SIP Statistics -> RTP Streams -> Analyze. This will
protocol trace looks correct. Try a test run in which the bring up the analysis window, with each stream
inbound or outbound call is made, then look closely at under a different tab.
the results. These guidelines describe a quick checklist: o Streams may be saved separately or mixed as .au
• Are the IP addresses correct for the source and files (8000 HZ, 8-bit, mono PCM) by selecting the
destination systems or phones? Save Payload button. This brings up the Save
window, where it is possible to select Forward,
• The default SIP port is 5060 unless otherwise Reverse, or Both for the stream(s) to save. You must
specified. Check the port number in the UDP header. specify a directory in which to save and a file name.
• Are the addresses and ports correct for the Dialogic o The resulting .au audio file can then be heard on a
telecom board Ethernet NIC? system with a sound card with any audio player
• For a simple User-Agent-to-User-Agent session, the such as Windows Media Player or CoolEdit.
basic message flow will be similar to:
Troubleshooting Scenarios
o Caller ---- INVITE -- Called
This section presents in detail four real-world problems to
o Caller -- Trying ---- Called demonstrate common failure scenarios and how to address
o Caller -- Ringing --- Called them using Ethereal as an Ethernet packet monitor.

o Caller -- OK -------- Called SIP Signaling Working but No Voice

Symptom: An inbound call is made into an interactive
o Caller ---- ACK ----- Called
voice response (IVR) application on the system that uses
If you see this message flow, then the SIP signaling is the Dialogic telecom board. The SIP stack is external to
likely correct. the board. Based on the host SIP message, flow looks

5
Application Note Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products

normal (INVITE/Trying/Ringing/OK/ACK). However, Address Changed for Host Media Processing

no audio is heard when the SIP connection is complete. Software Host System
Symptom: A SIP call inbound to an IVR application on a
Analysis and Resolution: Initial trace examination shows
system based on HMP software proceeds normally. RTP
the expected SIP packets but no RTP packets. The SDP
streaming starts, but no audio is heard.
portion of the OK message returned by the IVR system
to the SIP call initiator (Cisco ATA) contains the address Analysis and Resolution: At first glance, SIP signaling
and port for the RTP stream back to the application. On looks normal. RTP streaming starts. However, closer
examination, the connection information field shows an inspection reveals that packets are going only in one
address of 192.168.1.9. However, the IP address of the direction – from the HMP software IVR system to the
system itself, used for SIP, is 192.168.1.101. This is not Cisco ATA that initiated the call. There are some packets
unexpected, since the Dialogic telecom board has its own heading in the other direction, but they are ARP Broadcast
Ethernet NIC, with an address of 192.168.1.9, assigned packets. (“Who has 192.168.1.100? Tell 192.168.1.115”.
when the board was configured. 192.168.1.115 is the IP address of the Cisco ATA.) That
At the same time, there is a string of Address Resolution makes sense. However, 192.168.1.100 is an old address,
Protocol (ARP) packets asking “Who has 192.168.1.9? not used anymore since the HMP software host was
Tell 192.168.1.115”. This means that the Cisco ATA recently moved and its address changed to 192.168.1.200.
(192.168.1.115) is requesting the MAC (unique hardware
Why is the ATA trying to find an old, unused address?
address) address that goes along with the IP address of
Looking more closely at the SDP portion of the OK sent
192.168.1.9. The NIC on the Dialogic telecom board
from the HMP software host to the ATA reveals an
itself would normally supply this information, but for
address of 192.168.1.100 in the Connection Information
some reason it is not responding.
field. That is how the ATA was instructed to stream to
Examination of the cabling shows that the RJ-45 that address, which it is unsuccessfully trying to find.
connector on the Dialogic telecom board has worked
When HMP software is installed, the system’s IP Address
itself loose. When it is reattached, normal operation
is entered as part of the process. Perhaps the RTP stack
resumes on the next SIP call.
does not get its NIC address from the IP subsystem itself?
Packets Lost to Local Loopback Interface That is indeed the case. The address entered as part of the
Symptom: On receipt of an INVITE method, all further install is kept in the Registry. When changing the system’s
SIP communication stops. RTP streaming does not start. TCP/IP address, the registry entry got out of synch with
the system's actual address.
Analysis and Resolution: If packets were going out, even
to an unwanted address, they still should be seen on the Reinstalling HMP software and specifying the new IP
NIC of the Ethereal system. However, application traces address will solve the problem. A quicker solution is to
indicate that the outgoing messaging is taking place. modify the address entry with Regedit, which you can
Examining the CallID in the SIP Message Header in the find at HKEY_LOCAL_MACHINE -> SOFTWARE ->
INVITE reveals that it contained, as part of the ID, an SBLabs -> dm3ssp -> IP_Addr0.
address of 127.0.0.1, which is the standard address of any
system’s local loopback interface. This leads to the source rfc2833 Type DTMF Not Working Properly
system’s /etc/hosts file, where it is found that the system’s Symptom: An IVR application and Snom SIP phone
name, bigsys, appears on the line specifying the local have been set up to work with rfc2833 DTMF tone
loopback address: generation, but DTMF recognition is not working.

127.0.0.1 localhost localhost.localdomain bigsys Analysis and Resolution: rfc2833 DTMF is a special type
of payload carried by an RTP packet. This type of DTMF
192.168.1.100 bigsys
does not rely on an audio representation of the tone, and
Removing the name from the first line resulted in an is thus more compact and reliable. However, both parties
address of 192.168.1.100 appearing in the CallID and its in a call must agree that rfc2833 is being used for the
use as the return address for subsequent messages. tone representation.

6
Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products Application Note

The Snom SIP phone has been configured for out-of- ulParmValue is set to 100, the application is recompiled
band DTMF (rfc2833) and a Dialogic® application set up and rerun, and subsequent test calls now have working
to handle the same sort of DTMF recognition. One side DTMF detection.
(or possibly both) is not working correctly.

The Snom SIP Phone has been configured to handle out- Conclusions
of-band DTMF with a payload type of 100. The The Open Source, PC-based network protocol analyzer
application should be doing the same. But what do these Ethereal can be a great help in an environment that uses
particular DTMF packets look like? After running even a telephony hardware and software. By understanding the
short test call, hundreds or thousands of RTP packets are special considerations for this environment as outlined
captured. Ethereal’s filter must be used to separate out the in this document, it is easy to get started debugging
voice from rfc2833 packets. This can be done as follows: Dialogic VoIP protocols using Ethereal.

• Stop the call’s trace. Product List

• Select a UDP packet. Dialogic® Host Media Processing Software System

• Use Tools-> Decode As -> Transport -> RTP -> • Microsoft Windows operating system
Apply to interpret the packets as RTP.
• Dialogic Host Media Processing Software
• Create a filter for RTP payload type 100 with:
• SIP under Global Call
o Edit -> Display Filters.
• Ethereal
o Add a Name for a new filter.
Dialogic® Telephony Hardware-Based System
o Select “Add Expression” button and scroll down
• Tech Support Chassis
and expand RTP entry.
• Dialogic® DM/IP241-1T1-PCI-100BT IP Board
o Select “Payload type”, “==” and enter a value of
100 for the payload. • Red Hat Linux operating system

o Accept and Save the new entry. • Dialogic® System Release Software

• Apply the filter by selecting the filter button on the • Vovida SIP
bottom left corner of the screen. This will bring up • Ethereal
the list of predefined filters, including the one just
created. Select and apply it. Cisco ATA 188

The RTP packets remaining in the trace are those with a • Two-line analog phone to IP gateway
payload type of 100. The first two digits of the payload • SIP software
correspond to the DTMF key pressed during the test call
– 01, 02, etc. So, the SIP phone seems to be doing its job. Snom 200

This leads to the other SIP endpoint. Examining the • SIP phone
application code reveals that it is expecting rfc2833 • Snom200-SIP
DTMF, but is actually looking for a different payload
Networking Equipment
type. The Dialogic® RTP streaming interface, once
open, has a number of parameters that can be set to • NetGear 8 Port Pro Series Dual Speed Hub, DS108
define the RTP sessions that will be used. Here,
ulParmValue in IPM_PARM_INFO has been set to 96,
indicating that a type 96 payload is expected. This does
not match the payload type sent by the phone.

7
Application Note Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products

References Acronyms
Dialogic product information — ACK SIP message sent by the caller after a final
http://www.dialogic.com response has been received for an INVITE
request.
Dialogic telecom support —
http://www.dialogic.com/support/ API Application programming interface
Communications Services Framework Project — ARP Address resolution protocol
http://sourceforge.net/projects/commsvcfw
ATA Analog telephone adaptor
Ethereal Project —
DTMF Dual tone multiple frequency
http://www.ethereal.com
GNU Open source software licensing from the GNU
Linux RPM Locator Website —
Project (http://www.gnu.org)
http://www.rpmfind.net
GUI Graphical user interface
Openxtra Ethereal —
http://www.openxtra.com/products/ethereal_xtra.htm HMP Host Media Processing
IP Internet protocol
IVR Interactive voice response
LAN Local area network
NIC Network interface card
rfc2833 RTP request for comment proposal for out-of-
band DTMF transmission
RPM Remote packet module
RTP Real time protocol
SDP Session description protocol
SIP Session initiation protocol
TCP Transmission control protocol
UDP User datagram protocol
VoIP Voice over internet protocol

8
Using Ethereal to Debug SIP and RTP on Dialogic® Voice over IP (VoIP) Products Application Note

9
To learn more, visit our site on the World Wide Web at http://www.dialogic.com
Dialogic Corporation
9800 Cavendish Blvd., 5th floor
Montreal, Quebec
CANADA H4M 2V9

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH PRODUCTS OF DIALOGIC CORPORATION OR ITS SUBSIDIARIES (“DIALOGIC”). NO
LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS
PROVIDED IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY
EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS
FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY.
Dialogic products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications.
Dialogic may make changes to specifications, product descriptions, and plans at any time, without notice.
Dialogic is a registered trademark of Dialogic. Dialogic's trademarks may be used publicly only with permission from Dialogic. Such permission may only be granted
by Dialogic’s legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9. Any authorized use of Dialogic's trademarks will be subject
to full respect of the trademark guidelines published by Dialogic from time to time and any use of Dialogic’s trademarks requires proper acknowledgement.
The names of actual companies and products mentioned herein are the trademarks of their respective owners. Dialogic encourages all users of its products to procure
all necessary intellectual property licenses required to implement their concepts or applications, which licenses may vary from country to country.
This document discusses Ethereal, which is an open source product. Dialogic is neither responsible for your decision to use Ethereal (or any other open source product)
in connection with Dialogic products including without limitation those referred to herein, nor is Dialogic responsible for any present or future effects such usage
might have, including without limitation effects on your products, business, or intellectual property rights.
Copyright © 2007 Dialogic Corporation All rights reserved. 9008-02 06/07

www.dialogic.com