Showing posts with label RTP. Show all posts
Showing posts with label RTP. Show all posts

The H.323 Protocol Stack

I would like to go over some of the components of the H.323 protocol stack next. The H.323 protocol stack is very complex and includes a number of components.

There are five main components to an H.323 stack. These are the Control section, the Data section, the Audio section, the Video section, and the Audio/Video Control section.

The Control section and the Data section are sent using TCP. The Control section uses H.245 control multimedia communication. This can include such things as opening and closing audio channels, negotiating the audio and video CODECs, sending and receiving DTMF signals, and managing information lights (i.e. message waiting, etc.). The Data section uses the T.120 standard to send communications and application protocols and services that support real-time multi-point communication. T.120 is a real-time data protocol and allows for communication of data such as a virtual whiteboard or other multimedia communications.

The remaining components of the H.323 stack are sent using UDP. The Audio portion of the stack includes the audio CODEC. H.323 supports the main CODECs discussed previously: G.711, G.722, G.723.1, G.728, and G.729a/b. I won’t go into detail about these CODECs again, but this is the portion of the stack that contains the actual voice data.

The Video portion of the stack indicates the video CODEC that is used for video calls. H.323 supports the H.26x family of video CODECs. These CODECs were designed by the International Telecommunications Union for use with a variety of applications, and were incorporated into H.323 for use with video conferencing. H.261 is a video stream for transport using the Real-Time Transport Protocol with any underlying protocols that carry RTP. H.263 specifies the payload format for encapsulating H.263 bit streams in RTP.

Finally, we come to the Audio/Video Control section. This is further subdivided into two sections – RTCP and RTP. I have discussed both RTCP and RTP previously, and it should come as no surprise that these two components are a part of the H.323 stack. RTCP is used by RTP to control and synchronize the streaming of audio and video. It provides feedback information to the source to adapt flow to changing network conditions.

That just about covers the information about the H.323 Protocol Stack. Further information is always available with a simple Google search (or Bing, if you so desire…but I wouldn’t recommend it!).

The RTP Header

The Real-Time Transport Protocol header contains a lot of necessary information for a VoIP (or any other real-time) communication. Major components include the RTP Timeclock, the RTP Timestamp, the Synchronization Source, the Contributing Source, the Payload Identification, the Sequence ID, and feedback on jitter.

The RTP Timeclock is an autonomous clock source that determines how many clock ticks have occurred. The RTP timestamp is a counter value that shows when a packet was created, and supports both silence suppression and jitter calculation. The Synchronization source (SSRC) is a unique, randomly-generated identifier that the RTP client uses to identify an RTP session, including which parties are talking and which are silent. The Contributing Source (CSRC) is an identifying list found after the RTP Packet Header, it preserves the identity of the original source. The Payload Identification is a traffic identifier, it identifies the CODEC being used. The Sequence ID is part of the header information, and contains information regarding the order that the packets were sent in. The Feedback on Jitter portion of the RTP header provides potential adjustments that will be required for the possible buffer adjustment.

Since RTP is a connectionless protocol it does not provide feedback to the sending computer. To address this issue the Real Time Control Protocol (RTCP) has been added. RTCP provides end-to-end delivery services for real-time traffic, including monitoring QoS and providing some feedback in QoS reports. It also prvides additional information about the sender, such as the name, telephone number, etc.