Avaya Network Packet Sniffers

The 4 techniques to help you identify RTP Media Streams with Avaya Core Solution

In this post “Avaya Network Packet Sniffers” learn how tethereal, tcpdump, dumpcap, and tshark can help us start troubleshooting common VoIP/SIP issues related to connectivity, registrations, and sometimes confirming if the voice stream is being carried over throughout the network by reviewing the packet captures from these Network Analyzers.

Packet Sniffers help us provide detailed information to Service Providers, and assist Avaya System Administrators find solutions to their SIP Trunk problems by providing a concise report of the Voice transmission flowing through the network. Network Packet Sniffers help find SIP UA registration problems, faulty Media Processors by collecting the data traversing from the End-User through the Avaya Core systems, among other things.

Here are the 4 techniques to help you identify issues related with VoIP=

• 1.- Assess the environment
• 2.- Know the technology
• 3.- Collect or Duplicate
• 4.- Update the configuration

1.- Assess the environment

When assessing the customer’s environment it is important to know who is affected, which resources is this particular User using, the direction of the call, time/date, and finally the location associated with the user.

2.- Know the technology

Whatever system implemented, H.248 Gateways or IP Office, you need understand where the RTP Stream is generated by these devices. A VoIP or VCM resource is used whenever there are IP Phones using digital T1s, analog POTS lines, or SIP Trunks with Digital/Analog phones. In other words when a TDM resource is handled an RTP Media Stream gets created by the Gateway/IP Office Media-Processor/Voice-Compression Module.

Keep in mind there are two paths created whenever generating a single call. A signaling path, and voice/media path. Signaling messages and RTP-Media Stream information events are reported in a single session or phone call when interpreting these messages in your trace.

RTP-Stream Play Functionality – We are limited to playback the call based on where these Packet Sniffers are collecting the data from, for instance if you run packet captures in SM or CM you only see the reported resources utilized in the call. To play-back you need to capture the SBC interfaces or run the Packet Sniffers in a networked computer.

Some SBCs like the SBCE saves a group of files available for playback. SONUS SBC allows you to setup captures based on interfaces, protocol, etc. and similar to SBCE lets you play-back the calls.

3.- Collect or Duplicate

In my case I had a remote users having issues with “one way audio”. By using Packet Sniffers, in this case dumpcap I was able to collect packet captures to analyze the events based on call logs provided by the customer.

Collecting the Data

These are linux servers therefore you should be familiar with each kernel and commands available. Test each command and variation to confirm that you are collecting the data intended.

The following are three Packet Sniffers available with the Avaya Core solution=

tshark – It is a CLI-Based wireshark tool that collects packet captures.

tshark basics – When capturing network information it is important to know the Interfaces available, the command “tshark -D” displays the interfaces from where you can start your capture.

-D switch is available with the other tools to find the mounted interfaces in your server.

Naming and extension – When naming the Packet Captures try to keep it consistency, ending with the extension “pcap”.

Other tshark commands variations=

nohup tshark -i eth2 -b file size:50000 -b files:20 -w /home/cust/OneWayAudioCalls.pcap >/dev/null &

The above command run the tshark application script in the background (nohup + & at the end of the script)

• The -i switch captures from Network Interface
• eth2 – For Session Manager Ethernet Interface 2 = SM100
• -b = ring buffer option
• -w = directory

tcpdump

We mainly use this on SBC SIPERA Servers, and it is very similar to tshark where you can filter and record specific network traffic information.

tcpdump -ni any -s 0 -vvv -C 100 -W 1000 -w /archive/pcapfiles/IPCS2/Customer.pcap &

the above command captures from any of the Interfaces A1 or B1 without converting host addresses. with -s 0 = telling tcpdump to collect the entire packet content, with “vvv” to display a more verbose output.  with -C= number of files and -W= Size per file.

-w = writes files to the specified directories and &= continuous file logging.

tethereal 

Similar to the other two packet sniffers you can capture different network traffic events. It is used more with CM Servers. Where tshark or dumpcap it is normally use with Session Manager and tcpdump with SBC SIPERA servers.

tethereal -R ‘sip contains “4500@yourdomain.com = Captures sip messages containing the SIP URI

tethereal -i eth0 -f “net 10.120.201.0/24” -b filesize:10000 -a files:20 -w /dir/path

tethereal -i any -R “sip.Method contains “INVITE”” = captures SIP INVITE Request Messages.

4.- Update the configuration

By reviewing the Network Packet Captures I was able to play-back the call and confirmed the SBC was sending the RTP-Media stream through the SIPERA. That lead me to continue troubleshooting internally where I found a bad Media Processor MP80 in a Media Gateway.

 

Question

How will you use these Network Packet Sniffers ?

 

Resources

See other variations of Packet Tools