In this lesson, we will investigate important numbers that appear in the transport of audio–218 and Port Numbers.
If you put a packet sniffer on a voice network, you might notice that very often, audio packets contain 218 bytes. This results from a default setting for voice: VoIP was developed from the standards of the telecommunication industry where the G.711 codec was commonly used. In the packet, each of two samples of 10ms of voice is encoded into 80 bytes. To the 160 bytes of voice, 58 bytes of Ethernet, IP, UDP, and RTP are added, making the total 218 bytes. These packets are sent 50 times per second.
In the audio industry, many different IP structures are used. Most often, audio is transferred using UDP with an industry-standard format for the actual audio data. In these cases, the key numbers are the source and destination ports in the UDP portion of the packet. The port number identifies the application code that is to send or receive the audio. Sometimes it is fixed by a standard. Other times it is negotiated during the session establishment. Or, it may be determined by the vendor when they develop the system software.
Why is this port number important? Occasionally it needs to be known to allow the audio traffic to pass through firewalls. This is one of the reasons you might hear the IT network staff talking about opening a port on the firewall. This port number is extremely useful in troubleshooting problems with audio on the network. For example, if you are having intermittent problems with audio transfer, you can put a protocol analyzer, such as Wireshark, on the network and set it to capture only traffic to and from the port(s) that are being used for that audio traffic. By doing this, you’ll be able to see only that traffic and know if frames are dropped, misrouted, or sent in a bursty manner.
Here are a few examples of how these port numbers are used in audio. The Clear-Com Eclipse 9.1 HX Software on a system with an IVC-32 card or E-IPA card communicates to external devices using 6001 as the default TCP or UDP ports. This configuration is designed to be deployed over the LAN, WAN, or the internet. However, that value can be set by the user to any valid port number to accommodate routing needs. The Helixnet partyline system, which is intended for LAN use, utilizes UDP port 5353 for mDNS discovery, UDP port 6001 for audio, and TCP port 6000 for pairing such devices as remote speakers and belt packs. mDNS is a discovery technique similar to the way a hosts file is used in Windows to replace DNS. However, ports in this configuration are fixed and cannot be changed by the system administrator.
With the knowledge above, we can put a packet sniffer on our network and capture traffic that is isolated to the function for which these ports are used. This may allow us to see such traffic for a period of weeks and months rather than for a few minutes or hours.