Native Videoconferencing based on H.323 Rodrigo Rodrigues, António Grilo, Miguel Santos and Mário S. Nunes INESC R. Alves Redol nº 9, 1 Lisboa, Portugal Abstract Due to the potential of videoconference as a communication service, ITU-T has issued several standards that try to regulate its transmission and control protocols. is considered a good transmission media for this kind of traffic, due to its ability to assure quality of service (QoS) parameters. In this paper we identify the disadvantages of the current videoconferencing standards, and propose a new protocol stack for videoconference over. In the new protocol stack, the different streams are transported directly over, without any additional network layer protocol. The feasibility of the proposal is demonstrated by a prototype application. I. INTRODUCTION The videoconference market has been developing rapidly over the past few years, due to three main reasons: improvements in audiovisual quality, lower costs, and an international effort towards standardization. The improvement in audiovisual quality is due to the development of efficient video and audio compression methods. The cost of videoconference systems has been drastically reduced in two fundamental areas, namely, communications, and terminal equipment. The latter has particularly changed since the processing speed of personal computers allowed them to be used has terminals for multimedia communications. The main communication infrastructure that has been used for videoconferencing is Narrowband ISDN, or N- ISDN. The main limitation of N-ISDN is that each channel only allows transmitting 64 kbits per second (bps), which imposes that several N-ISDN channels have to be opened in order to obtain a fixed (constant rate) bandwidth multiple of 64k bps. The fact that it is a constant rate channel represents a large waste, since the video compression methods usually originate a variable rate stream. More recently, a new transmission technology has arrived (Asynchronous Transfer Mode - ) that is well suited for transmitting real-time streams, due to its ability to assure quality of service (QoS) for data with diverse traffic patterns [1]. On the other hand, the fast growing of the Internet, along with improving performance of Local Area Networks (LANs), has encouraged the development of international standards for videoconferencing based on the IP protocol stack. One of them, H.323 [2], has imposed itself as the most widely used standard in telephony and videoconferencing, restricting based standards to dedicated videoconferencing equipment, or employing IP over methods in order to allow using H.323. The latter solution has the obvious disadvantages of not taking advantage of QoS, and using IP addresses, which face the serious risk of running out of available addresses in the next decade. Currently, is trying to impose itself has the best transmission technology for multimedia traffic. For that reason, there is a strong need for the development of native applications, i.e. applications using directly the protocol stack, without any network layer protocol on top of it, namely IP. In this paper, we present a solution that consists of an adaptation of H.323, although it doesn t use any IP related protocol. Therefore, all functionality up to the transport layer is supported by related protocols, and QoS characteristics are assured. The remainder of the paper is organized as follows. Section II gives a brief summary on the existing standards in this area. Section III describes how we adapted those standards to produce the new H.323 protocol stack. Section IV outlines the prototype application s architecture. Section V shows some experimental results, and finally section VI draws some conclusions and indicates the possible future work. II. VIDEOCONFERENCING STANDARDS ITU-T has issued several recommendations concerning videoconferencing. We will present them and identify their disadvantages. H.32 [3] specifies a multimedia terminal for transmission over the N-ISDN network. I.4 Signaling H.242, H.23, H.221 Control System G.711,G.722,G.728 N-ISDN interface Fig. 1 H.32 protocol stack H.261 As it can be seen in Figure 1, it s not a flexible standard, since the use of N-ISDN imposes very strict encoding rules for audio and video. H.321 [4] is an adaptation of H.32 to B-ISDN environments. Therefore, a terminal conforming to this recom-
mendation interworks with other H.321 terminals accommodated in B-ISDN as well as existing H.32 terminals accommodated in N-ISDN. The temporal characteristics of the 64 kbps channels of N-ISDN are emulated using the CBR service of AAL1. Thus, several 64 kbps virtual circuits (VCs) are established to perform the same functions as the N-ISDN B channels. Reliable Delivery H.225. Call Control TCP Unreliable Delivery Audio/Video Streams RAS RTCP UDP IP LLC H.242, H.23, H.221 Control System User-network H.2 / AV25 H.261 MAC Fig. 4 H.323 protocol stack Physical Layer AAL1 Fig. 2 H.321 protocol stack Although this recommendation has the obvious advantage of easy interoperability with H.32, it is still too dependent of the H.261 video encoding, and it requires the use of AAL1, not supported by most commercially available interface cards. Furthermore, the resolution of an H.321 terminal is limited to the CIF quality (352x288 pixels) specified in the H.261 standard. The purpose of the H.31 terminal [5] is to provide a higher resolution capability as defined by the H.262 (MPEG-2) video coding standard. User-network SAAL Q.21 User-user G-series, H.2/AV.255 H.222. AAL H.261 / H.262 H.222.1 Although networks provide that QoS guarantee, this recommendation is very important because of its flexibility. In fact, the use of the Real Time Transport Protocol () as defined in H.225. [6] for packetization and synchronization instead of H.222.1 [7] allows different channels to be opened for audio and video streams. Additionally, the control protocol (RTCP) offers mechanisms to adapt the output bandwidth according to the quality perceived by the receivers, as we will describe later. Moreover, prior to the connection establishment there is a negotiation using [8] that can allow audio and video encoding other than the already specified G.711, G.722, G.723, G.728 and G.729 for audio or H.261 and H.263 for video. The growth of the Internet has increased the importance of this standard, and even Microsoft has incorporated this protocol in the most recent version of NetMeeting [9]. Although H.323 can be used on networks by employing an IP over method, that solution is less efficient than using VCs directly, because it doesn t use the QoS features of. More recently, an annex has been added to this recommendation, H.323 annex C [1], that optionally allows users to establish QoS-based connections using without employing any IP related protocols, except for the control plane. Whenever reliable delivery is needed TCP/IP is employed. Physical layer Fig. 3 H.31 protocol stack Both these recommendations have the disadvantage of being strongly dependent of the H.261 or H.262 encoding for synchronization and buffer management, which raises two issues: it won t allow either using other codecs, or the definition of different QoS parameters for audio and video channels. Meanwhile, the H.323 recommendation [2] was developed to address the problem of visual telephone systems for Local Area Networks (LANs) which provide a nonguaranteed Quality of Service. Reliable Delivery Unreliable Delivery H.225. Audio/Video Streams Call Control RAS RTCP TCP UDP IP Fig. 5 H.323 annex C protocol stack
H.323 annex C is much more flexible than H.31, since solves both of the problems mentioned above. Still, it is strongly dependent of the IP protocol, since it has to use IP addresses in the call establishment phase, leaving the use of addresses (E.164) for audio and video channels only. Given the limitations of the current version of IP, which is reaching the end of its useful life, and the fact that IPv6 is unlikely to become available in the short term, addresses present a good alternative to the use of IP addresses in the future. III. PROPOSAL OF A NEW PROTOCOL STACK In order to overcome the limitations of the recommendations discussed thus far, we propose a protocol stack with the following characteristics [11]. It uses only addresses (E.164), allows different channels to be open for audio and video with different QoS parameters and even different service classes for each kind of traffic, allows the use of any audio and video encoding, and shows good interoperability with the existing standards, in particular with H.323 for the reasons stated above. Therefore, we tried to keep from H.323 a certain degree of flexibility that was brought by the usage of the protocol to pack and synchronize the different streams. was kept as the control protocol, allowing the negotiation of audio and video formats other than those specified. Call Control SSCOP Application SSCF RTCP Audio / Video streams Fig. 6 Videoconference over Native protocol stack As we can see in the proposed protocol stack, IP is no longer used, and all functionality up to the transport layer is supported by related protocols implemented in every commercial protocol stack. A reliable delivery is needed for call control. In order not to use both IP and related protocols, we replaced the use of TCP in H.323 annex C with SSCOP, which also provides reliable delivery, and has the advantage of being implemented in most commercially available protocol stacks. Another suitable alternative would be the use of TCP over Native, as proposed by Grilo et al. [12]. ISDN is also replaced by () for call establishment and termination. As in H.323, the protocol is used to carry both audio and video streams, therefore allowing different VCs to be opened for audio and video channels. The control part of the protocol, RTCP, is used for several purposes, namely to identify the different parties, and to obtain a feedback on the quality of the reception, allowing each sender to dynamically adapt the quality of the recording to the available bandwidth and processing capacity of the receivers. Interoperability of this proposal with H.323 terminals is easily achieved by means of a gateway, since both protocol stacks are quite similar. On the data plane there is no need for conversions, so the only difficulty would be the translation between and IP addresses and vice-versa. The responsibility of that translation would be up to the H.323 Gatekeeper entities, as defined in the H.323 recommendation [2]. IV. APPLICATION ARCHITECTURE In order to demonstrate the feasibility of this proposal, a prototype application was developed. This application was based on two main programming interfaces (APIs): the Windows Sockets 2 (WinSocks 2) and the Video For Windows (VFW) interfaces. The WinSocks 2 interface [13] is an extension to the most widely used network programming interface for Windows: Windows Sockets 1.1. It maintains backward compatibility, and extends the previous interface in several areas such as enabling access to protocols other than TCP/IP using the well known socket interface, having support for QoS definition, and having generic multicast and multipoint primitives, amongst other extensions. As we show in Fig. 7, the use of this API to allow Native communication is simply achieved by choosing the appropriate service provider (SP). In our implementation we used a FORE card, and its Native SP for Win- Socks 2. Proprietary Interface Native Videoconference Application WinSock 2 FORE Native SP for WinSocks 2 FORE card driver (includes UNI) FORE card Fig. 7 drivers and interfaces for Windows The VFW interface has three main modules, used by this application. The capture module allows the digitization of the audio and video streams, and the control of the various capture parameters, such as number of captured frames per second or the image size. The compression module hides the
details of image and sound compression and decompression through the invocation of generic functions. Finally, the playback module will perform audio and video playback. LOSS (%) 1 CONGESTED PACKET LOSS LOSS RATE FEEDBACK λ c LOADED FILTER λ u UNLOADED CAPTURE COMPRESSION NETWORK DECOMPRESSION PLAYBACK Fig. 1 Network classification as seen by the receivers VIDEO STREAM Fig. 8 Video stream The audio capture and compression, unlike the video, usually generates a constant rate stream. Therefore, we chose an optimal amount of samples to send in each packet, allowing the overhead introduced by headers and padding bytes to be reduced, in some cases, from 13% to 9% [14]. As we mentioned previously RTCP offers a flow control mechanism that allows the sender to dynamically adapt the output bandwidth according to the quality perceived by the receivers that is transmitted in the RTCP receiver report (RR) packets. The architecture of the bandwidth control system is depicted in Fig. 9. Then, we adjust the output bandwidth to the network state by changing the capture frame rate, increasing it if the network seems unloaded or decreasing it if it appears to be congested. We also defined minimum and maximum frame rates to guarantee a minimal picture quality, and to avoid unnecessary frame rate which does not improve the perceived quality. Furthermore, in the case of congestion the application should rapidly reduce its bandwidth. Thus, we use a multiplicative decrease in case of congestion and an additive increase in case of a small loss rate. This scheme was already known from TCP s slow start [16]. The VCs opened during a videoconference session are listed in Table I. Table I VCs in a videoconference session DATA RTCP SR network Descr. Service Class Bit Rate AAL SSCOP Audio CBR Codec No Dependant Video VBR, ABR Codec No or UBR Dependant CBR 64 kbps Yes RTCP UBR - No RTCP RR Fig. 9 Dynamic bandwidth control architecture The algorithm implemented to adapt the quality of the recording, and therefore the output bandwidth, to the receivers status was proposed by Busse [15]. Basically, the sending application retrieves the other participants packet loss from the RR packets. These measurements are smoothed using a low-pass filter to avoid reacting to small oscillations. Then, the smoothed value is used to classify the network state as seen by the receivers as unloaded, loaded or congested, according to the distinction in Fig. 1. The audio stream has a constant bit rate, and therefore a CBR channel is used for audio. The use of a 64 kbps CBR channel for is recommended in H.31 [5]. As we have explained before, this recommendation also specifies the use of a reliable delivery channel. In order to achieve that, we use the SSCOP protocol. RTCP is not very demanding in terms of bandwidth, so we open a UBR channel for that protocol. V. EXPERIMENTAL RESULTS We ran several experiments in order to show the functioning of the application. First, we compared the overhead of the native solution versus UDP/IP. In order to do that, we measured the packet size of a typical videoconference situation, and we compared the packet size in a native and a UDP/IP transmission.
Packet size increase IP vs. (%) 12 1 8 6 4 2.5 1 1.5 2 2.5 3 Time (s.) Fig. 11 Packet size increase using UDP/IP As we can see in Fig. 11 the percentile increase of the UDP/IP transmission versus the native solution is appreciable, averaging 2.7%. Obviously, this increase is more significant when packet sizes are smaller. If we only considered the audio stream the total packet size increase of the UDP/IP transmission was 9.4%. In the next figure, we demonstrate the behavior of the dynamic QoS adjustment algorithm. Losses (%) 4.5 4 3.5 3 2.5 2 1.5 1.5 1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 Time (s.) Losses Smoothed Losses Fig. 12 Dynamic QoS adjustment algorithm results We can see that when the loss rate raises, the frames per second value decreases abruptly, until the smoothed value reaches near zero percent loss. Then it raises slowly until there is a new peak in loss rate. VI. CONCLUSIONS AND FUTURE WORK In this paper we propose a new architecture for videoconference over native, based on the H.323 recommendation. The new architecture uses only protocols and addresses, allows different channels to be open for audio and video streams, and allows any type of audio and video encoding to be used. The exclusive use of addresses is an important feature of this system. The current version of IP is becoming obsolete because of its limited address space, and lack of QoS support. A solution to these problems is not likely to happen in the near future, since IPv6 deployment is currently frozen. As joins the longer NSAP/E.164 addressing with good QoS support, it is still a good candidate for the future Broadband ISDN. This was the approach followed in our fps 3 25 2 15 1 5 Frame Rate (fps) proposal, which defends the need for a new H.323 Annex for Native. We successfully implemented a prototype application and measured some experimental results showing some of the advantages of using networks in a videoconference system. In the future we expect to demonstrate the interoperability with the H.323 recommendation by developing a gateway between our proposal and H.323. Then it would be possible to have a videoconference session where some of the participants would use NetMeeting and the others would be on an network using our prototype application. Another good research issue would be to study which service class provides a better interaction with the dynamic QoS adjustment algorithm we use in our application. VII. REFERENCES [1] U. Black, : Foundation for Broadband Networks, Prentice-Hall, 1995. [2] ITU-T Recommendation H.323 Packet-based Multimedia Communication System, January 1998. [3] ITU-T Recommendation H.32 Narrowband visual telephone systems and terminal equipment, December 199. [4] ITU-T Recommendation H.321 Broadband Audiovisual Communication Systems and Terminals,November 1995. [5] ITU-T Recommendation H.31 Broadband Audiovisual Communication Systems and Terminals, June 1996. [6] ITU-T Recommendation H.225. Media Stream Packetization and Synchronization on Non-Guaranteed Quality of Service LANs, May 1996. [7] ITU-T Recommendation H.222.1 Multimedia multiplex and synchronization for audiovisual communication in environments, March 1996. [8] ITU-T Recommendation Control Protocol for Multimedia Communication, June 1996. [9] A. Davis, Microsoft s NetMeeting 2.: Why Desktop Videoconferencing s Rallying, Advanced Imaging, July 1997. [1] ITU-T Annex C H.323 on, January 1998. [11] A. Grilo, Videoconferência sobre nativo, IST, Lisbon, Portugal, M.Sc. Thesis, September 1998. [12] A. Grilo and M. Nunes, TCP Over Native (TONA), in SYBEN 98, Zurich, Switzerland, 1998. [13] Windows Sockets 2 Application Programming Interface An Interface for Transparent Network Programming under Microsoft Windows, Revision 2..8, May 1995. [14] Forum/98-253, Proposed text for voice payload sizes in H.323 over, April 1998. [15] I. Busse, B. Deffner and H. Schulzrinne, Dynamic QoS Control of Multimedia Applications based on, Computer Communications, vol. 19, pp. 49-58, January 1996. [16] V. Jacobson, "Congestion Avoidance and Control", in SIGCOMM 88, Stanford, Ca., August 1988.