H.323 Packet Activity

03/26/2020 29 People found this article helpful 487,677 Views

Description

Resolution

Overview

This article provides detailed information regarding the traffic flow of a standard H.323 VOIP packet transfer. This article will explain the expected packet transfer and help diagnose the breakdown in any missing packets. It will dialogue what is normally exchanged, and based on any missing pieces of this traffic exchange can give a direction to go in for troubleshooting. This will be based on packet capturing as well general settings in both the phone systems and the Sonicwall. Further this will apply to mainly Enhanced Units for settings.

Detailed Information

H.323 is the international standard for multimedia communication over packet-switched networks, including LANs, WANs, and the Internet. It was first defined by the ITU in 1996 and has been updated regularly. The most recent version is H.323 version 5 (2003).

H.323 is an "umbrella" specification, which includes the standards H.323, H.225.0, H.245, the H.450-series documents, and the H.460-series. It allows for the use of T.120 for data collaboration and file transfer. When referring to the system and set of documents, people generally refer to "H.323", though not every document is mandatory as part of a standard H.323 system. For example, H.460.2, which describes number portability, is generally not used in enterprise videoconferencing systems.

The scope of H.323 covers real-time voice, video, and data communication over packet-switched networks. It was designed from the outset to operate over IP networks, primarily, though H.323 may also operate over other packet-switched networks. It was designed with multipoint voice and video conferencing capabilities, though most users do not take advantage of the multipoint capabilities specified in the protocol.

The protocol H.323 includes four main exchanges:

H.225 for call signaling and call setup

RAS for registration and other admission control with a gatekeeper

H.245 for exchanging terminal capabilities and creation of media channels

RTP/RTCP for sequencing audio and video packets

These four exchanges are the main components to an H.323 VOIP call exchange. Keep in mind there can be several derivative implementations of this. Different vendors based on their programming and feature set adopt these variations dependant on what is needed in the call exchange. The presence of a Gatekeeper for example is an optional entity. One of its purposes is to provide basic admission control onto a network by authorizing (or refusing) communications between other H.323 entities within its zone of control. It also provides an address translation service, which can be used to convert numbers and IP addresses to names.

A Gatekeeper is an application that performs essential control, administrative and managerial functions. Generally supplied by a service provider as a value added service the Gatekeeper will usually be a public IP offered by the service provider or an application suite installed on the LAN.

These are the most common cycles of the call. This architecture will inevitably connect the call successfully if interoperability has been sufficiently planned for. When setting up VOIP deployments it is a good idea to know what protocols are being used. Below is a list of protocols used H.323 ties together a number of other protocols defined by the I.T.U. or the I.E.T.F. Some vendors may have a proprietary codec for audio or video, this is not very common and its best to refer to the VOIP vendors documentation to troubleshoot.

G.7xx codecs

This series of recommendations define the way in which analogue voice signals may be translated to a digital form and optionally compressed in bandwidth. Examples include G.711 and G.729.

H.26x codecs

These recommendations define methods for digitizing analogue video signals.

H.225.0

This protocol has two purposes. If an optional gatekeeper entity exists in a network, then H.225.0 defines the means by which a terminal may register with that gatekeeper and seek admission to the network. Even if a gatekeeper is not present, H.225.0 defines the way in which endpoints communicate with each other to setup or clear down calls. In the latter case, H.225.0 is used in conjunction with Q.931.

H.245

Having established a connection between two endpoints using H.225.0 and Q.931, H.245 is used between the terminals (or other endpoints) to establish the logical channels through which the media will transmitted.

Q.931

Q931 is a call signaling protocol used extensively in ISDN networks for setting up and clearing down calls. Q.931 is also used for establishing H323 calls. H.225.0 call control messages are embedded within the user-to-user elements of Q931 messages to provide additional information not available in Q.931 such as IP address information.

RTP

RTP is the protocol used to provide timing and synchronization for digitized voice and video being transmitted through a packet network. When transmitted through an IP network, RTP relies on the lower layer UDP protocol to transport it through a network between computer applications. RTP is not discussed further in this document, but there is a white paper available that describes the IP/UDP/RTP protocols.

RTCP

RTCP is closely related to RTP. It defines a protocol mechanism for terminals to provide feedback regarding the quality of media received using RTP. RTCP is transmitted using UDP between dynamically allocated sockets.

T.120

T.120 defines a means of exchanging data during a multimedia call. Applications may include file transfer, chat, application sharing and whiteboarding. T.120 is transmitted using a number of TCP channels.

Below is a call being setup between two endpoints:

Non-Standard H.323 Traffic

Below is an example of some non-standard H.323 traffic, TFTP traffic (Trivial File Transfer Protocol), between a call manager and an IP phone. This illustrates traffic that is not normally exchanged as part of a standard H.323 Call. The body of the packet is in clear text and shows what is being exchanged. This stage acts as a parameter check on the phone, directory synchronization, and firmware versions.

In this capture, in clear text of the body of the packet, you see the parameters exchanged by the phones to the central IP-PBX. Settings, firmware versions, applications being used within the firmware are exchanged during this file transfer.

Example of TFTP transfer:

Standard H.323 Traffic

First, the H.225 call signaling is exchanged. The RFC Port is 1720, but is not limited to this port only. If a call never connects, this will indicate problems with the initial call-signaling handshake. The first portion of the call there is a RAS registration with the Gatekeeper from each member of the call. If this stage of the call does not connect then this is indicative of a problem with a misconfiguration on the phone regarding its Gatekeeper.

The RAS handshake is a validation process between the Gatekeeper and the members of the conversation. RAS (Registration, Admission, Status) is a management protocol between terminals and gatekeepers.

Below is the same system has a successful in the RAS Registration.

Figure 1 – RAS registration and confirmation.

Below is the same system experiencing a failure in the RAS Registration.

Figure 2 – H.225 RAS Failure

The first portion of call signaling includes announcements of each member of the call and registration with the gatekeeper. A packet capture will show clear text that the call setup, alert and alert responses are received. There is IP information in these setup packets that will indicate if a packet is being tagged with a LAN address or a WAN address. This will indicate if the IP Phone is doing H.323 transformations or if the Sonicwall needs to be. It is standard to have either “Auto-Discovery” mode or “NAT”. The Sonicwall is recommended to NAT to the IP Phones. This will avoid any addressing conflict, another option in is to use transparent mode, and set the IP of the Phone to its Public IP address. If the phone is setup to use “Auto-Discovery” then H.323 transformations should be turned off the Sonicwall. The additional option is to use SIP transformations. SIP protocol is a separate method to make VOIP calls and requires a SIP server along with an HTTP-like negotiation of "Session-based" IP call-handling.

The next step of the exchange of H.323 is H.245, this is the hand-off of what multimedia communication, such video and audio codec versions that are to be used. This is also displayed in the packet datagram, and will indicate a mismatch in codec versions. Once the Parameters of the multimedia codecs have been exchanged the connection will open up RTP/RTCP (Real-Time Transport Protocol/Real-Time Transport Control Protocol) streaming. These packets are UDP and normally use a dynamic porting to manage its connectionless state.

Example of a successfully completed H.323 Call:

Notice that the CS (Call Setup) moves directly into the H.225 setup and alerting, and then moves into a H.225 connect this is setup over port 1720. Then H.245 gathers the Teminal information from the respective endpoints and the role determinations for the call.

The completed negotiation will result in a connection state called “OpenLogicalChannel”, this indicates a successful negotiation between endpoints and the opening of the RTP/RTCP threading over UDP. This is started in packet number 34.

Troubleshooting Tips

There is an important piece to get H.323 VOIP to work. If there is a DF bit present, which there is when prioritization is involved, and the DF bit is ignored this will break stream compression and packets that should not be fragmented are. It seems that in most all VOIP cases with this “Ignore DF Bit” is checked and there is a fragmentation enabled on the interface there most likely is no call completion.

This can also result in “wobbling”, a choppy call. In VOIP communications, when there is a QoS component, via software, or firmware, the DF bits are critical to stream compression. If the DF packets are ignored then the Data stream will break, in cases when there is reassembly enabled this will result in packets dropping on the endpoint.

This most likely will occur after the H.245 call setup, just as the call looks to be completing, in this case the call will look like its connecting, but there is no sound, or in some cases no video. So uncheck “Ignore DF Bit” when there is QoS based application in place. This is a good practice in that in some cases the QoS can be handled by the hardware on the IP-PBX in this case the information on what is doing QoS is not readily available.

Summary

In troubleshooting VOIP its important to know what protocols are being used first. Then be sure that you are logging this traffic. If the calls are not connecting then its important to know a little about the stages of the call, and to diagnose at what stage there is a break in traffic. To do this, a packet capture can help dialogue the activity between endpoints and when present a Gateway. By getting a packet capture it will illustrate the IP information in place, this can be crosschecked with the network topology for any wrong IP addresses. The topology plays an important role in these setups, and it is recommended when implementing VoIP to have a current network diagram that maps the environment where the system resides.

Not Finding Your Answers?

ASK THE COMMUNITY

Was This Article Helpful?

YES NO

H.323 Packet Activity

Description

Resolution

Related Articles

Categories

Not Finding Your Answers?

Was This Article Helpful?

Article Helpful Form

Article Not Helpful Form

Follow Us

Subscribe to newsletter

Stay In Touch