D1Vol1.doc

Project P913-GI Real-time services on the Internet Deliverable 1 Road-map for current real-time services over the Internet Volume 1 of 2: Main Report Suggested readers: • Participants in P913-GI • Staff of Shareholders responsible for or involved in the provision of real-time Internet services • Staff of Shareholders who are involved in offering services over the Internet with real- time and guaranteed bandwidth requirements • R&D engineers working on or interested in advanced Internet services • Managers at Shareholders involved in Internet services For full publication May 1999

EURESCOM PARTICIPANTS in Project P913-GI are: BT Deutsche Telekom AG France Télécom Portugal Telecom S.A. This document contains material which is the copyright of certain EURESCOM PARTICIPANTS, and may not be reproduced or copied without permission. All PARTICIPANTS have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information. This document has been approved by EURESCOM Board of Governors for distribution to all EURESCOM Shareholders. © 1999 EURESCOM Participants in P913-GI

Deliverable 1 Volume 1: Main Report Preface (Prepared by the EURESCOM Permanent Staff) Real-time services over the Internet are gaining increasing importance and attention from customers, who expect reduced costs and from operators who need to open new markets. The Internet, designed as a connection-less transport technology poses, however, considerable challenges if used over and as replacement of connection- oriented network systems, especially when real-time and high quality are main requirements. Real-time conversational services, such as Internet telephony are currently being deployed and it is expected that they will rapidly gain a share of the market. More demanding real-time services, such as audio/video streaming or multiparty conversational services still suffer from many technical problems which need to be resolved before realistic success can be expected. The Project will investigate both AV-streaming and multi-party conversational services and will test how these services will perform in best-effort Internet and with Internet solutions which offer some bandwidth control. From these results possible scenarios, recommendations on protocols and solutions for access networks, Internet and Internet Gateways will be produced. As key results the Project will produce: • A Roadmap for key issues on real-time streaming services over the Internet • Knowledge about the abilities and constraints of IP based real-time technology today. • Recommendations about solutions, possible configurations and protocols to be used for the deployment of real-time streaming services over Internet in Europe. The Project started its activities on January 1999 and will be finished in December 1999. The Project is led by Hans-Detlef Schulz (Deutsche Telekom, MTG). BT, DT, FT and PT are participating in the Project. © 1999 EURESCOM Participants in Project P913-GI page i (x)

Deliverable 1 Volume 1: Main Report Executive Summary Beside the tremendous success of the Internet that is widely visible, there is also the trend that many applications that have been offered in a connection oriented mode over different kinds of networks, are now moving towards the Internet. Audio-video streaming applications, such as Music-on-Demand, Video-on-Demand and Games are concerned as well as conversational applications such as audio-video conferencing, video telephony, and so on. These are called real-time services over the Internet. The main actors in the Internet industry are now drawing their attention to promote real-time services. The different standardisation bodies and software manufacturers are also focusing on this topic. Why you should read this Deliverable? Most current real-time activities lead to bandwidth requirement issues, and are currently subject to new product announcements and new versions of Internet related standards. The purpose of the Project is to analyse and to give recommendations on the way to step from existing best-effort Internet services towards some extent of bandwidth provision, in relation to user and application requirements. This Deliverable is the first stage of this process. Actually, the goal of the Deliverable is to provide a state-of-the-art document about real-time services. It has 2 advantages: • First it provides a general summary of what is related to real-time services today, from the Internet technology to the market trends. Since many studies, products and standards are developing day after day, it is important in the scope of the Project to identify the main actors. Therefore the first purpose of the document is to get a clear vision of the area and to draw an exhaustive list of the key-topics related with real-time services: the technology, the products offered, the standardisation and the trends in the marketplace. • Secondly it identifies all critical elements related to real-time services, in order to step from best effort internet to some bandwidth provision, and to introduce the next tasks in the Project (i.e. the testing of applications under best effort conditions and under bandwidth control). What are the topics discussed in this document? The main body of the document draws a global view of: • The Internet technology in general, i.e. the protocols, the access, the security issues, the main classic services • The real-time services: real-time constraints, protocols issues, best effort versus bandwidth control • A summarised review on items related to real-time services over the Internet, such as the standardisation, the tools and commercial products and the market trends • The analysis of the road-map: the areas to focus on and the areas of less interest regarding Internet issues and real-time requirements, the test scenarios and the summary and conclusion part © 1999 EURESCOM Participants in Project P913-GI page iii (x)

Volume 1: Main Report Deliverable 1 Furthermore, a separate technical annex describes more specifically the three detailed topics summarised in the main Deliverable: • the state-of-the-art of the standardisation (IETF, ITU-T, DAVIC,…), for the transport layer, the application layer and the encoding techniques • The assessment of industrial solutions and products for real-time services: audio- visual streaming products and video-conferencing tools • The market trends regarding services which are currently available What are the main benefits of this Deliverable? The benefits depend on the readers. First, the output of this document can be used by the Project participants, as it gives the guidance for Task 3 and 4, by identifying the key-topics that are analysed in detail. Thus Section 4 focuses on the introduction of best effort Internet versus bandwidth control, listing different possibilities and configurations of the application scenarios selected by the Project, and the issues which are of less interest. Furthermore the Deliverable gives the guidance for the clients of the Project: • to understand the approach, • to interpret the results, • to understand why specific emphasis is placed upon certain issues relating to bandwidth provision on the Internet, • to understand why other issues are considered to be of less interest. The last benefit is for the shareholders in general: the document contains a detailed description of the state-of-the-art in the area of real-time services. It describes many topics in a synthetic form, including parts from different expert sources of information. The content tries to be as exhaustive as possible, as detailed as feasible, with links to some references to get more specific items. However, the access to the information remains as direct as possible and the content aimed at being easily understood. Therefore this Deliverable should allow the shareholders’ customers to understand what issues need to be addressed in order to move from best-effort Internet to the introduction of some bandwidth control. page iv (x) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report List of Authors Kevin Wilson BT Andrew Auchterlonie BT Hans-Detlef Schulz DT David Girault FT Stephane Pallavicini FT João Paulo Firmeza PT © 1999 EURESCOM Participants in Project P913-GI page v (x)

Volume 1: Main Report Deliverable 1 Table of Contents PREFACE...........................................................................................................I EXECUTIVE SUMMARY.............................................................................III LIST OF AUTHORS........................................................................................V TABLE OF CONTENTS................................................................................VI ABBREVIATIONS.........................................................................................IX 1 INTRODUCTION..........................................................................................1 1.1 The Socrates Project..................................................................................1 1.2 Aim of this Deliverable..............................................................................1 1.3 Structure of this Deliverable......................................................................2 2 UNDERSTANDING THE INTERNET TECHNOLOGY..........................5 2.1 Introduction................................................................................................5 2.2 Protocols.....................................................................................................5 2.2.1 Characteristics of IP (Internet Protocol)............................................5 2.2.2 Characteristics of the transport protocols : TCP & UDP..................5 2.2.3 Protocol hierarchy..............................................................................6 2.3 The Network..............................................................................................7 2.3.1 Multiple physical networks..................................................................7 2.3.2 Addressing process..............................................................................8 2.3.3 The routing..........................................................................................8 2.3.4 Routers, Bridges, Gateways, Switches..............................................10 2.3.5 Access................................................................................................10 2.4 Current Internet Services.........................................................................10 2.4.1 HTTP & the Web...............................................................................10 2.4.2 Telnet.................................................................................................11 2.4.3 File Transfer......................................................................................11 2.4.4 Mail...................................................................................................11 2.4.5 News..................................................................................................12 2.4.6 Other..................................................................................................12 2.5 Security on the Internet............................................................................12 2.5.1 Problems of Security.........................................................................13 2.5.2 Firewall.............................................................................................13 2.5.3 Proxy Server......................................................................................13 2.5.4 Tunnel................................................................................................13 2.5.5 Gate keepers......................................................................................13 2.6 Global view..............................................................................................14 3 UNDERSTANDING THE ISSUES FOR REAL-TIME SERVICES......17 3.1 Downloading services..............................................................................17 3.2 Real-Time Services..................................................................................17 3.2.1 Definition...........................................................................................17 3.2.2 Server to people applications: AV streaming services......................18 page vi (x) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report 3.2.3 People to people applications : conversational services..................18 3.2.4 Currently offered services.................................................................18 3.3 Constraints of real-time services..............................................................20 3.3.1 Real-time constraints.........................................................................20 3.3.2 Internet specific issues.......................................................................21 3.3.3 Quality requirements.........................................................................21 3.4 Protocol issues..........................................................................................23 3.4.1 UDP versus TCP...............................................................................23 3.4.2 Real-Time protocols..........................................................................23 3.4.3 Transmission modes..........................................................................24 3.5 Best Effort versus Bandwidth Control.....................................................25 3.5.1 Best Effort services............................................................................25 3.5.2 Services with Bandwidth Control......................................................26 4 REVIEWS ON ITEMS RELATED TO THE INTERNET REAL-TIME SERVICES.......................................................................................................31 4.1 Standards for Real Time Internet Services..............................................31 4.2 Tools and Commercial Products..............................................................31 4.3 Market Trends..........................................................................................32 5 ANALYSIS OF THE ROAD-MAP............................................................33 5.1 Main constraints for current real-time services.......................................33 5.2 Main issues involved by the Internet Technology...................................34 5.2.1 The packet loss..................................................................................34 5.2.2 The end-to-end delay.........................................................................34 5.2.3 The network jitter..............................................................................34 5.2.4 The end-to-end bandwidth.................................................................34 5.2.5 The packet size..................................................................................35 5.2.6 The network topology........................................................................35 5.2.7 Acceptable level of quality ...............................................................36 5.3 Feasibility in best effort Internet versus bandwidth control network......37 5.3.1 Services currently working under Best Effort Internet......................37 5.3.2 Services currently using Bandwidth Adaptation...............................37 5.3.3 Services getting benefit from Bandwidth Control.............................38 5.3.4 Services currently using Bandwidth Control at the application level ....................................................................................................................38 5.4 Proposed access scenarios........................................................................38 5.4.1 Access scenarios for best-effort Internet...........................................38 5.4.2 Access scenarios for a network with bandwidth control...................39 5.5 Implications and prioritisation for Task 3 & Task 4 of the Project.........39 5.5.1 Areas of less interest..........................................................................39 5.5.2 Areas to focus on...............................................................................39 5.6 Application scenarios selected by the Project..........................................40 5.6.1 Conversational aspects......................................................................40 5.6.2 Streaming aspects..............................................................................41 6 CONCLUSIONS...........................................................................................43 REFERENCES................................................................................................45 © 1999 EURESCOM Participants in Project P913-GI page vii (x)

Deliverable 1 Volume 1: Main Report Abbreviations A/V Audio/Video ADSL Asymmetric Digital Subscriber Line AF Assured Forwarding AoD Audio-on-Demand AQUAVIT Assessment of QUality for Audio-Visual signals over Internet and UMTS ARP Address Resolution Protocol ATM Asynchronous Transfer Mode BGP Border Gateway Protocol BRFQ Bit Round Fair Queuing CBQ Class Based Queuing CLIP Classical IP CPU Central Processing Unit DAVIC Digital AudioVIsual Council DHCP Dynamic Host Configuration Protocol DiffServ Differentiated Services DNS Domain Name Service/Server DTMF Dual Tone Multi Frequency EBONE European backBONE EF Expedited Forwarding ETSI European Telecommunications Standards Institute FAQ Frequently Asked Questions FDDI Fibre Distributed Data Interface FIFO First-In-First-Out FQ Fair Queuing FQDN Fully Qualified Domain Name FTP File Transfer Protocol GPS Global Positioning System HDLC High level Data Link Control HTML Hypertext Mark-up Language HTTP HyperText Transfer Protocol IAB Internet Architecture Board IAP Internet Access Provider ICMP Internet Control Messaging Protocol IGMP Internet Group Management Protocol © 1999 EURESCOM Participants in Project P913-GI page ix (x)

Volume 1: Main Report Deliverable 1 IGP Internal Gateway Protocol IGRP Interior Gateway Routing Protocol IETF Internet Engineering Task Force IntServ Integrated Services IP Internet Protocol IPCE InterProcess Communication Environment IRC Internet Relay Chat IRTF Internet Research Task Force ISDN Integrated Services Digital Network ISO International Standard Organisation ISP Internet Service Provider ITU-T International Telecommunication Union - Telecommunications JUPITER Joint Usability, Performability and Interoperability Trials in Europe L2TP Layer 2 Tunnelling Protocol LAN Local Area Network LLC Logic Link Control MBONE Multicast backBONE MIME Multipurpose Internet Mail Extensions MoD Music-on-Demand MP3 MPEG1 Audio – Layer 3 MPEG Moving Pictures Expert Group MPOA Multi Protocol Over ATM NAS Network Access Server/Service NBMA Non Broadcast Multiple Access NIC National Information Centre NNTP Network News Transfer Protocol NoD News-on-Demand OSI Open Systems Interconnect OSPF Open Shortest Path First PC Personal Computer PHB Per Hop Behaviour PIN Personal Identification Number PPP Point-to-Point Protocol PPTP Point-to-Point Tunnelling Protocol PQ Priority Queuing PSK Phase-Shift-Keying page x (x) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report PSTN Public Switched Telephone Network QoS Quality of Service RFC Request For Comments RIP Routing Information Protocol RSVP Resource reSerVation Protocol RTCP Real Time Control Protocol RTP Real time Transport Protocol RTSP Real Time Streaming Protocol SAP Session Announcement Protocol SDH Synchronous Digital Hierarchy SDLC Synchronous Data Link Control SDP Session Description Protocol SIP Session Initiation Protocol SMIL Synchronised Multimedia Integration Language SMTP Simple Mail Transfer Protocol SOCRATES Streaming and Online Conversational Real Time Services TCP Transmission Control Protocol UDP User Datagram Protocol URI Uniform Resource Identifier URL Uniform Resource Locator VCR Video Cassette Recorder VoD Video-on-Demand W3C World Wide Web Consortium WAN Wide Area Network WDM Wavelength Division Multiplexing WFQ Weighted Fair Queuing WRED Weighted Random Early Detection WWW World Wide Web © 1999 EURESCOM Participants in Project P913-GI page xi (x)

Deliverable 1 Volume 1: Main Report 1 Introduction 1.1 The Socrates Project Project P913-GI, also called SOCRATES (Streaming and Online Conversational Real Time Services), deals with real-time services over the Internet. Beside the success of the Internet and its most popular applications (the news, e-mail, the World Wide Web), some unusual services are phasing in. These are applications which were originally intended to be used over connection oriented networks, i.e. audio-visual broadcasting, telephony, video-conferencing, among others. Both standardisation bodies and industrial companies are taking into account this new feature of the Internet: real-time services. Talking about real-time applications like Video, Audio, or other streaming data over the Internet leads to some constraints where time is the most critical element. Therefore some parameters such as delay, jitter and packet loss can have a significant impact on the quality of such services over the Internet. In that way, offering real-time applications via the Internet leads to bandwidth requirements from an application point of view and to help ensure acceptability by the users. Bandwidth provision in the Internet is an issue which is currently subject to new product announcements of manufacturers and new versions of Internet related standards. P913-GI aims to analyse the step from existing Best-Effort Internet to some extent of bandwidth provision and will consider different possible technical solutions, and will relate these to different user and application requirements. Recommendations will be provided to the shareholders so that they are able to offer real-time services over the Internet under the appropriate bandwidth conditions. 1.2 Aim of this Deliverable This Deliverable has the purpose of providing a state-of-the art analysis (also called roadmap) in the area of real-time services. It is the very first step in the Project, aiming at setting the basis for a common understanding of the different topics in the Internet world related with real-time applications. Therefore, this document illustrates the full scenario of current activities to provide real-time applications over the Internet and the different approaches. It considers both the best effort Internet and the network with bandwidth control, and identifies the significant elements that are related to bandwidth provision. Moreover, the Deliverable makes a review on the current standards, the different products on offer and the current market trends. At minimum it aims to explain the purpose of the application test scenarios selected by the Project. In that way, the Deliverable has the form of a short handbook, which includes: • The description of the Internet technology: the protocols, the network, the main services and the security issues. • The description of real-time services: real-time constraints, protocols issues, best effort versus bandwidth control. • The assessment of industrial solutions for real-time applications: audio-visual streaming products and video-conferencing tools. • the state-of-the-art of the standardisation (IETF, ITU-T, DAVIC,…), for both the transport layer, the application layer and the encoding techniques. © 1999 EURESCOM Participants in Project P913-GI page 1 (45)

Volume 1: Main Report Deliverable 1 • The market trends regarding the services which are available. • The implications and prioritisation for task 3 & task 4 in the Project. Moreover, two major topics are to be considered in this document: • the best effort part, which should give knowledge about the state-of-the-art in the area without any assumption being made about the availability of resources of the Internet, • the quality-aware part, which should produce a complete report about the current situation in the area with regard to the bandwidth control (bandwidth reservation, QoS levels). To sum up, the goal of this document is to provide a clear and detailed report about the current situation in the area of real-time services, and to give the guidance for the following tasks of the Project. 1.3 Structure of this Deliverable This Deliverable is the first task of P913-GI activities. It describes the key-topics that have an impact on the provision of real-time applications over the Internet. Thus it is structured as follows: • Section 2 describes the Internet technology and draws a current picture of what is related to the Internet today: the protocols, the network, the major downloading services and security issues. • Section 3 focuses on the main issues regarding real-time services: real-time constraints, protocols issues and best effort versus bandwidth control. • Section 4 is a general summary of the reviews on topics related to real-time services: review of the standardisation, review of products, market trends. It links to references described in the Annex document. • Section 5 provides the analysis of the road-map, and identifies the key-topics to be studied in the Project: the constraints of real-time services versus the issues of the Internet technology, the feasibility in best effort Internet compared with bandwidth control, the proposed test scenarios, the implication for Task 3 and Task 4 and finally, the application scenarios selected by the Project. Besides this main body of the Deliverable, some detailed topics are provided as technical annexes in a separate document (D1Annex.doc). This annex document is structured as follows: • Section A makes a detailed review on current standards related to the real-time services: the main standardisation bodies, the IP Suite of Protocols, including the real-time protocols and reservation protocol, the audio and video standards, the proprietary encoding schemes and the coding techniques description. • Section B makes a review on the available or announced products, for both the audio/video streaming applications and the conferencing tools, and a comparison table is provided. • Section C focuses on market trends, considering both the available technology and products: it explores the business segment (internet technology, software technology, content oriented applications, offers from network operators, service providers), the geographical areas (north America, Europe, Asia Pacific region), the behaviour of users (private, public or corporate), the quality requirements and the market development. page 2 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report 2 Understanding the Internet technology The purpose of this section is to describe the Internet technology and to draw a current picture of what is related to the Internet. 2.1 Introduction The Internet is a set of physically interconnected networks which communicate using a common protocol: Internet Protocol (IP). Originally developed by the US Defence to create a distributed computer network, it has been enlarged to be used by the general public. Its use is free: charges are only made for connecting to the local ISP, but not for the ability to transport data from almost anywhere around the world. The first public users were the computing engineers of the US Research department in the 70’s. It was then extended to the world-wide universities in the 1980’s. In the 1990’s, commercial companies started to get access to the Internet, and the general public in 1994. The Internet is administrated by the NIC which manage the domain names. Several structures can drive the studies: the Internet Architecture Board (IAB) takes care of its technical development, the Internet Engineering Task Force (IETF) writes the standards, the Internet Research Task Force (IRTF) drives the evolution of the network, the World Wide Web Consortium (W3C) drives the evolution of a particular service called the Web. Besides the Internet, an Intranet Network is by extension a private network that uses the IP protocol, and where a network administrator has to manage the evolution and the security on his network. An Extranet network is an extension of a corporate Intranet which allows certain partners outside of the private Intranet to gain access to all or some of the Intranet. 2.2 Protocols The purpose of this section is to provide general elements on the kind of protocols that can be found in the Internet community. 2.2.1 Characteristics of IP (Internet Protocol) The Internet Protocol is designed for use in interconnected packet-switched computer communication networks. The Internet protocol provides for transmitting blocks of data called datagrams from sources to destinations, where sources and destinations are hosts identified by fixed length addresses. The Internet protocol also provides for fragmentation and reassemble of long datagrams, if necessary, for transmission through "small packet" networks. The Internet protocol is specifically limited: there are no mechanisms to augment end- to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. 2.2.2 Characteristics of the transport protocols : TCP & UDP For the transportation of datagrams, 2 protocols are generally used in the Internet: TCP and UDP. © 1999 EURESCOM Participants in Project P913-GI page 5 (45)

Volume 1: Main Report Deliverable 1 2.2.2.1 TCP1 The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks. TCP allows data transmission controlled with acknowledgements, and uses slow start and congestion control mechanisms. TCP is a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols which support multi- network applications. This protocol is mainly used by services where reliability is critical such as the World Wide Web, File Transfer, e-mail and on-line news. 2.2.2.2 UDP2 The User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP). This protocol assumes that the Internet Protocol (IP) is used as the underlying protocol. This protocol is mainly used by services such as DNS requests and real-time applications, where applications are geared toward time performance rather than reliability. 2.2.3 Protocol hierarchy Figure 1 shows an example of the construction of an IP packet for an e-mail application: User Message SMTP SMTP Header User Message Source Destination TCP Port Port Control Data 1 Source Dest IP Control Address Address IP Option Data 2 Figure 1: IP Packet for e-mail data Figure 2 compares the OSI layered structure model with the TCP/model. It illustrates the place of the Internet protocol in the protocol hierarchy. 1 See Annex A.2.2 for description 2 See Annex A.2.3 for description page 6 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report OSI model TCP/IP model 7 application application HTTP, SMTP, FTP, NNTP, TELNET, RTSP 6 presentation 5 session RTP, RTCP 4 transport transport TCP, UDP, routing protocols 3 network network IP, ICMP, RSVP 2 link Data network Ethernet, FDDI, PPP 1 physical physical Modulation Figure 2: OSI & TCP/IP layered models 2.3 The Network 2.3.1 Multiple physical networks IP is not dependent on the underlying physical network over which it runs on. This characteristic has been pointed out as one of the main advantages of the Internet Protocol, and goes some way to explain why the facility has grown so rapidly world- wide. Traditionally, IP is supported on both LAN (where broadcast mechanisms are available) and WAN networks. It is also supported on several non-broadcast multiple access (NBMA) and broadcast multiple access networks. On local area network technologies, such as Ethernet (from 10Mbps to 1Gbps), token- ring or FDDI networks, IP runs over the networks own data link layer standards, such as, for Ethernet, 802.2 LLC. On these networks, the translation between network addresses and IP addresses is accomplished by using the Address Resolution Protocol (ARP). On the WAN, IP can run over HDLC, SDLC, PPP, X.25 or frame-relay. These are the traditional ways of transporting IP on the Internet backbones. IP can also run over ATM networks, by using one of these standards: RFC 1483, Classical IP (CLIP), Lan Emulation (LANE) or Multi-protocol over ATM (MPOA). Recently, new standards are being developed to allow IP transport over SDH and WDM networks. © 1999 EURESCOM Participants in Project P913-GI page 7 (45)

Volume 1: Main Report Deliverable 1 2.3.2 Addressing process As the IP is based on an addressing process, a mechanism was needed to provide unique addresses which were independent of the kind of network and independent of the access. A distinction is made between names, addresses, and routes. A name indicates what we seek. An address indicates where it is. A route indicates how to get there. The Internet protocol deals primarily with addresses. It is the task of higher level (i.e., host-to-host or application, for example the Domain Name Server request process) protocols to make the mapping from names to addresses. The Internet module maps Internet addresses to local net addresses (i.e. the physical address). It is the task of lower level (i.e., local net or gateways) procedures to make the mapping from local net addresses to routes. IP Addresses are fixed length of four octets (32 bits). An address begins with a network number, followed by local address (called the "rest" field). The names are described by the Fully Qualified Domain Name (FQDN) and are of type: name@organisation.domain for people or computer_name.organisation.domain for a computer. A URL (Uniform Resource Locator) is a compact string representation for a resource available via the Internet. URLs are used to `locate' resources, by providing an abstract identification of the resource location. In general, URLs are written as follows: <scheme>:<scheme-specific-part> 2.3.3 The routing The Internet is a packet-based network which breaks large messages into a series of smaller packets or datagrams which are transported across the network in an individual, mutually exclusive fashion. With the Internet, packetisation usually occurs at two levels. For a connection which uses TCP/IP, the original message is split up into TCP packets and these are then placed inside IP packets. TCP packet headers are responsible for indicating which TCP ports are to be used for the session, as well as arranging for acknowledgement and re-transmission packets. The IP packet header is responsible for indicating the source and destination addresses which are used by the routers to determine the optimum route for each packet. TCP/IP is discussed in more detail in Annex A. The addresses of the source and destination hosts are 32-bit numbers of the format 193.113.209.147 in IPv4, or 128-bit numbers of similar format in IPv6. Since the average human finds it difficult to remember numerous 12-digit numbers but easier to remember text strings, these numeric addresses can also take the form of text strings. These text addresses have the following format: protocol://domain/directory. When the address of a host is entered textually the computer needs to convert the text string into the actual numeric IP address. It does this by means of look-up tables in the Domain Name System (DNS) Server. For example, if the URL http://www.eurescom.de was entered, the DNS Server would look up the entry for www.eurescom.de and return the corresponding IP address. The IP address can then be used for to route the packets across the Internet. The aim of any routing algorithm is to route packets from source to destination in a timely, efficient manner. The routing algorithm should be simple in order to minimise the computation required and robust enough to be able to withstand node and/or link page 8 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report failures. The algorithm should also seek to be fair to all network users and should be optimised for throughput or minimum delay. Some of these goals are in direct conflict with one another and a trade-off must be made between conflicting goals: e.g. maximum efficiency is achieved when all links are permanently full, but this is sure to introduce delay to messages as they wait in routing buffers. There are numerous types of routing mechanisms which can be used to ensure packets get from their source to their destination. Some of these mechanisms require the algorithm to have knowledge about the configuration and status of the network, while others require no such knowledge. Each routing mechanism has it’s own relative merits and problems. The routing protocol which was used initially on the Internet was Routing Information Protocol (RIP). This protocol is based on a Distance Vector Algorithm. The Distance Vector is a table which is computed by each node in the network and contains information about the ‘distances’ between a node and all other nodes in the network. The vectors are transmitted to all adjacent nodes in the network frequently to enable them to update their own Distance Vector tables. A number of metrics can be used to evaluate the ‘distance’ between nodes, including the hop count, delay, physical distance and error rate. RIP was used as the original routing protocol for the Internet and is still used in individual IP networks today. RIP exhibited some problems in that it tended to count to infinity when computing routes. An improved version of RIP, RIPv2 had improved support for classless IP addresses and was more resistant to security attacks which attempted to subvert routing in IP networks. An alternative to Distance Vector Algorithms is Link State Algorithms. In Link State Algorithms, each routing node evaluates the delay to neighbouring nodes and distributes this information to all other nodes using a flooding mechanism. Each node then uses all the received information to find the optimum shortest path to all other nodes. Dijkstra’s Algorithm is one such example of a Link State Algorithm and this type is now the favoured algorithm in IP networks. The Internet now uses Open Shortest Path First (OSPF), a link-state-based algorithm. However, RIPv2 is still used relatively widely, especially for multicasting. OSPF can take into account QoS factors when computing routes, and can perform load balancing by distributing traffic equally amongst routes which have the same cost. In addition, OSPF uses multicast instead of flooding to distribute routing information to other nodes, reducing the volume of routing traffic on the network by a significant factor. OSPF does, however, require very powerful processors, as it is computationally complex. Since the Internet is a network of interconnected smaller networks, it makes little sense to perform routing on an Internet-wide basis. If this were done, routing tables would be overwhelming and the computation of all routes would take a long time. Instead the complete network is divided up into areas and nodes/routers within each area only need to determine whether or not the destination address is within it’s own area or in a separate area. If the destination is within the local area, routing proceeds using one of the routing algorithms discussed earlier. If the destination is outwith the local area, the packet is routed to the designated border gateway which routes the packet to the appropriate area where it can be routed to the destination host. This scheme implies that there is a logical backbone network which connects areas together. A protocol called Border Gateway Protocol is used between border gateways to exchange information about ‘reachability’. The information transferred contains the list of areas that must be transversed in order to reach the destination area. Once the packet has reached its destination, the local routing algorithm forwards the packet on to the relevant host. © 1999 EURESCOM Participants in Project P913-GI page 9 (45)

Volume 1: Main Report Deliverable 1 2.3.4 Routers, Bridges, Gateways, Switches The following definitions are limited to the Internet area. In other areas they could be indeed slightly different. A router is a dedicated computer which is attached to two or more networks and forwards packets from one to the others (it provides the interconnection at the network level). In particular, an IP router forwards IP datagrams among the networks to which it connects. It uses the destination address on a datagram to choose a next-hop. A bridge is also a computer that connects two networks and forwards packets, but it operates at the physical networks level (bridges use layer 2 -data link- addresses, while routers use IP addresses – layer 3). A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server's protocol. It provides the interconnection between networks at the application level. Sometimes routers are also called gateways. A switch is also a dedicated computer which acts as a multi-port bridge (speaking in the Internet area). It uses in order to forward packets the data link address. It makes traditionally the connection between several LANs and replaces more and more hubs (which act at the physical layer) and bridges. 2.3.5 Access In order to access the Internet, you have to go through an IAP (Internet Access Provider) or an ISP (Internet Service Provider) which provides the external transit, connectivity and, for the ISP, associated services. The user can be connected either by PSTN, ISDN, ADSL or Cable (when provided) to access his ISP. An interface needs to be used between the computer and the physical network such as a modem or an add-on ISDN card. A NAS (Network Access Server or Services) is a device used to terminate dial-up access to a network. It is usually used for analog or digital dial-up PPP (Point to Point Protocol) access services. 2.4 Current Internet Services 2.4.1 HTTP & the Web The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content. HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used. page 10 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report The primary use of HTTP is called the Web service. An application interface, called a browser, enables the navigation through HTML pages located on a server, retrieves the information and decodes and display’s them. 2.4.2 Telnet The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. A TELNET connection is a Transmission Control Protocol (TCP) connection used to transmit data with interspersed TELNET control information. A TELNET connection is established between the user's port U and the server's port L. The server listens on its well-known port L for such connections. Since a TCP connection is full duplex and identified by the pair of ports, the server can engage in many simultaneous connections involving its port L and different user ports U. When used for remote user access to service hosts (i.e., remote terminal access) this protocol is assigned server port L=23. 2.4.3 File Transfer The primary functions of the File Transfer Protocol (FTP) are to transfer files efficiently and reliably among hosts and to allow the convenient use of remote file storage capabilities. The objectives of FTP are : 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs. The FTP uses the Telnet protocol on the control connection. 2.4.4 Mail Simple Mail Transfer Protocol (SMTP) specifies a protocol dedicated to transfer mail reliably and efficiently, based on its capability to relay mail across transport service environments. A transport service provides an interprocess communication environment (IPCE). The SMTP design is based on the following model of communication: as the result of a user mail request, the sender-SMTP establishes a two-way transmission channel to a receiver-SMTP. The dialog is purposely lock-step, one-at-a-time. The SMTP transmission channel is a TCP connection established between the sender process port U and the receiver process port L. This single full duplex connection is used as the transmission channel. This protocol is assigned the service port L=25. © 1999 EURESCOM Participants in Project P913-GI page 11 (45)

Volume 1: Main Report Deliverable 1 2.4.5 News Network News Transfer Protocol (NNTP) specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. The news server uses a stream connection (such as TCP) and SMTP-like commands and responses. It is designed to accept connections from hosts, and to provide a simple interface to the news database. This server is only an interface between programs and the news databases. It does not perform any user interaction or presentation-level functions. These "user-friendly" functions are better left to the client programs, which have a better understanding of the environment in which they are operating. When used via Internet TCP, the contact port assigned for this service is 119. 2.4.6 Other • Internet Relay Chat Protocol The IRC is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. IRC itself is a teleconferencing system. The IRC protocol has been developed on systems using the TCP/IP network protocol, although there is no requirement that this remain the only sphere in which it operates. • IP Telephony IP telephony services allow the fully integration between the Internet and the telephony networks, enabling users to seamlessly place calls over the Internet (or a private IP network) from a regular phone-to-phone, from PC-to-phone or phone-to-PC or from PC to PC, like if they were using conventional voice services from telecom operators. • Facsimile over the Internet There are two different types of Internet facsimile that have recently been standardised by the ITU: Store-and-Forward Internet Fax (defined in ITU-T Recommendation T.37) and Real-Time Internet Fax (defined in ITU-T Recommendation T.38). Store- and-Forward Internet Fax is of no relevance in the concept of Real-Time applications over the Internet. • Videoconferencing Videoconferencing is a multimedia service which is aimed mainly at the business market. It consists of a multimedia application which allows multipoint (or two-way) meetings and can include streaming of audio-visual content and dataconferencing. Audio is generally considered to be the crucial element of the conference, with video regarded as an added value element. Dataconferencing is becoming more and more important in many specific scenarios since it allows cooperative work by application sharing (especially word processing). Videoconferencing systems can be either specific systems or computer applications (which may use added hardware boards for audio/video compression). These applications can be standards-compliant or a proprietary solution. 2.5 Security on the Internet Many concepts are involved in Internet Security. There are three Firewall concepts and different protocol level security concepts. The Firewall technologies are: page 12 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report • Packet Filtering Firewalls (see section 2.5.2 Firewall) consist of two or more network interfaces (often one Internet access and one LAN access). Beside this physical accesses, the firewall has three sets of rules: 1 set for each access, specifying which communications are allowed on which interface, and a set of forwarding rules. • Application Level Firewalls (see section 2.5.3 Proxy Server) are checking which data may pass through, by inspecting the data at the application level, e.g., by recognising data to be from a user that was already authenticated, and hence the data may pass through. Application Level Firewalls are dependent on the application in use (e.g. HTTP, FTP, mail etc.). • Stateful Inspection Technology (see section 2.5.5 Gate Keepers) is a technology that analyses data on all 7 layers of the OSI-model. Communication protocol security (see section 2.5.4 Tunnel) is used on Layer 2 for encryption. Two such tunnelling protocols are in use: L2TP and PPTP. 2.5.1 Problems of Security The main problems security addresses deal with protection against external or internal attacks of a network. Some solutions have been carried out in that way to improve security issues : • Authentication and encryption mechanisms • Authorisation checking, filtering (on the basis of @IP, protocols, ports’ numbers, ...) • Accounting • Autoconfiguration (DNS, Gateway, @IP ... and other possible parameters) using DHCP for example. 2.5.2 Firewall The Firewall is designed both for filtering (policy to reject/authorise datagrams depending on their field contents) and relaying packets (application forwarding agent). 2.5.3 Proxy Server A proxy is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by the URI. 2.5.4 Tunnel A tunnel acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages. 2.5.5 Gate keepers Gate Keepers technology is based on an inspection of data from all communication layers that are stored by state and context data. This data is checked by the security rules and as a result of this check, passed, dropped or encrypted. Stateful inspection © 1999 EURESCOM Participants in Project P913-GI page 13 (45)

Volume 1: Main Report Deliverable 1 technology (or Gate Keepers) realisations are conceptually more powerful than Packet Filtering or Proxy Server technology, but realisations are still facing problems, due to high complexity. 2.6 Global view There are a very large number of services and applications which run over the Internet and many of these use different connection procedures and transport protocols. Some of the more advanced services (such as a multicast web-conference) use some very complex transport, routing and signalling systems. However, a basic service, such as downloading a web-page from a remote host can be explained quite easily. In this example, we assume that a person is using a dial-up connection to an ISP to download a web-page which contains an HTML page with various graphics. When the user dials into the ISP and all the necessary login requirements are fulfilled, the ISP dynamically assigns the user an IP address from the ISP’s pool of addresses using PPP. The user’s computer can be connected to the ISP via either an analogue modem or an ISDN connection. Analogue modems convert digital information into analogue signals for transmission over the local-loop telephone network using a range of Phase-Shift-Keying (PSK) schemes. ISDN connections do not require this conversion and generally perform better than analogue modems, although ISDN lines cost more to lease and are not supported by all ISPs. Once the user has been assigned an IP address, they are seen logically by the ISP as a client of the ISP server. The user would like to visit the EURESCOM homepage, and so keys ‘http://www.eurescom.de‘ into their web-browser. The local Domain Name System (DNS) server (which may belong to the ISP itself or a third party) is then contacted and the look-up tables are searched to retrieve the numerical IP address for www.eurescom.com. The IP address is then used to send a TCP connection request to TCP port 80 on the EURESCOM web server. When this request is confirmed, the server assigns the connection an arbitrary TCP port which will be maintained for the duration of the communication. Once the connection has been set up, an HTTP (Hyper-text Transfer Protocol) request is sent to the EURESCOM web server. By default, the request will be for a file called index.htm unless any specific sub-directory and/or file name is specified. The web server executes the request and returns the relevant file, which is (probably) in the Hypertext Mark-up Language (HTML) format. This file may have references to images or other files which reside on the same server or a different server. For each of these references, a separate TCP connection request is sent, and a separate TCP port number is assigned. Once each file has been received intact, the relevant TCP connection is closed. This is a very general overview of what happens, and it is possible to go into more detail. The files to be transferred are of variable size and will usually need to be split into a number of smaller segments which are placed into the payload section of the TCP packet. The contents of the TCP packet header are discussed in Section 3.2.3. The TCP packet is then mapped into the payload section of an IP packet, the header of which contains information relating to the source and destination addresses of the packet. This addressing information is read by each of the routers along the packet’s path. The routers forward the packet on to the next router in the path based on a routing algorithm as discussed in Section 1.3.3. Note that the routers do not decide upon the complete optimum path from source to destination. They simply decide which of the output links the packet should be forwarded on based upon the destination of the packet and the routing tables stored in the router’s memory. This example is based on a simple process of downloading a web-page to a computer which is connected to the Internet via a dial-up ISP. If the user is connected via a corporate LAN which uses Ethernet, the IP packets which are received at the LAN’s page 14 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report Internet gateway must be encapsulated within Ethernet packets and then delivered to the user via the LAN. An IP address would be assigned to the user either on a permanent basis or on a temporary basis using DHCP (Dynamic Host Configuration Protocol). Other types of media transport are possible, such as real-time video and audio streaming. For these transfers, a slightly different sequence of events may take place, and different protocols may be used. However, the above example highlights the general principles of Internet communications. © 1999 EURESCOM Participants in Project P913-GI page 15 (45)

Deliverable 1 Volume 1: Main Report 3 Understanding the issues for real-time services The purpose of this section is to describe what is called “real-time services”, for a common understanding of the area, and to preview the problems involved with that kind of services. 3.1 Downloading services A pure downloading service is File Transfer (FTP): a connection is established and data is transferred to a local storage device. Then it can be processed locally using an application that can interpret the format of the data. The World Wide Web service is not really a downloading service, but it can not be called real-time transmission neither. Currently a Web browser can deal with some basic data, such as text, still or animated pictures, sounds, video. This data is usually encoded and/or compressed to minimise bandwidth requirements. As they are carried by the HTTP protocol, the browser can start to reconstruct some parts of html files as the loading of other parts is in progress. However, once they are fully received, the connection is closed with the server. An important point is that there is no synchronisation between the different kind of data with the common presentation formats such as html (this problem will be resolved with the SMIL format). The Push service is also somewhere between downloading and real-time transmission. 3.2 Real-Time Services 3.2.1 Definition In an asynchronous environment such as the Internet, a real-time service can be defined as a service where the time is the main constraint. For example, for full duplex applications such as IP telephony or videoconferencing, the transmission delay should not exceed a minimum threshold in order that a correct exchange can be established without losing spontaneity. On the other hand, while significant delay is not acceptable, some reduction of quality might be feasible. In other examples, such as Video-on-Demand or Audio-on-Demand, there are configurations where a delay (e.g. 2 seconds) between transmission time and presentation time causes no problem, but a variation or reduction of quality during presentation cannot be accepted. Real-time services that are considered by P913-GI are services for which time constraints exist between: • The transmission and the reception and/or between • The transmission and the presentation of the data. Additionally, there may be quality requirements that are imposed on the reception or presentation of the data. Due to this overlapping situation it is necessary, to investigate the different real-time services in more detail and to consider them one by one. For classification, Internet A/V real-time applications can be divided in two groups : “people to people” and “server to people” applications. © 1999 EURESCOM Participants in Project P913-GI page 17 (45)

Volume 1: Main Report Deliverable 1 3.2.2 Server to people applications: AV streaming services In contrast with downloading services, streaming services enable the playout of the data while the reception continues. In the “server to people” group, there are two types of services: “distribution” and “individual access”. Radio and TV live broadcast and corporate broadcast applications belong to the first service; AudioOnDemand and VideoOnDemand applications belong to the second one. All these applications require that data are received at the same rate it was sent. 3.2.3 People to people applications : conversational services Under “people to people” types of applications, two types of services may again be distinguished: “interactive” and “distribution”. Telephony, videotelephony and videoconference applications belong to the first service; conference and meeting broadcast applications belong to the second one. Interactive applications require that any transmission delay is reduced to its minimum. Videoconferences and other such people-to-people interactive applications are multipart services, which means that the service has different components such as Audio, Video, still-image, filetransfer etc. With these types of service, different communication channels are normally opened for the transfer of each media component. A specific analysis is necessary to analyse the different kinds of real-time constraints that apply to the different media and channels, and their combination. 3.2.4 Currently offered services P913-GI is focussed on real-time applications over the Internet that have some enhanced bandwidth requirements so that the border-line between best effort Internet and introduction of some bandwidth control can be investigated. Therefore, even if it is detailed below, services like Internet telephony are not in the scope of this Project. Real-time services that could be considered by P913-GI are detailed in Sections 3.2.4.1 to 3.2.4.9. 3.2.4.1 Video-on-Demand (VoD) VoD is a server to people application, where users can download video-films. Depending on the details of the offered service, the real-time aspect may not allow any delay between transmission, presentation and user action (i.e., when the typical VCR functions are offered to the user). In other VoD realisations that offer no interactivity during presentation, some small delay between the transmission and presentation to the user may be acceptable. Pure download, without direct presentation, is out of the scope of P913-GI. Reduction of quality may be a feature that could be considered to guarantee throughput. 3.2.4.2 Music-on-Demand (MoD) MoD is a server to people application, where users can download songs or CD. Real- time aspects do not require strong interactivity, and hence, some small delay between transmission and presentation may be acceptable. Pure download, without direct presentation, is out of the scope of P913-GI. Reduction of quality seems not a feature that could be considered. page 18 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report 3.2.4.3 News-on-Demand (NoD) NoD is a server to people application, which consists of the same type of data as the broadcasting applications, but which is based on On-Demand (individual) delivery. Therefore, Quality reduction is a feature that may apply to this type of application. On the other hand, interactivity, like in VoD is normally necessary, and therefore, delays should not be significant. 3.2.4.4 Broadcasting Broadcasting is a server to people application, to provide several users in parallel with immediate access to video, and audio sources. Delay in the presentation would be purely local and cannot be accepted as a feature. Reduction of quality seems difficult to be considered in such a distribution from one to many configurations. 3.2.4.5 Video-telephony Video-telephony is people to people application, where two users are having an audio- conversation with the option to see each other. Delays are not acceptable, as this is an immediate real-time communication. Even synchronisation between audio and video has a high importance. Quality reductions seem to be acceptable at least in the video part. 3.2.4.6 Conferencing Conferencing is a people to people application where two or more users are opening different communication channels to each other (via some conference control) each of which covers a different type of information e.g. Still image, File Transfer, Audio and Video between other participants in the conference. The quality requirements and the real-time requirements of each of this different media may be very different. File transfer for instance, needs full quality (bit-wise), while normally it has no strong requirements on delays. The major problems in describing the real-time behaviour of conferences come from the variety of aspects of different media. Videoconferencing was traditionally deployed over ISDN. Though the installed ISDN-based systems remain important, desktop applications over IP (Intranet or even Internet) are becoming more and more popular. This is due to the improvement of PC performances, better and easier interfaces and low cost hardware availability. Videoconferencing, on a large basis, implies the set up of Multipoint Control Units (MCU), Gateways, Gatekeepers and specific switches. It also needs all-important bandwidth. Moreover it implies the offering of a satisfying quality of service in terms of guaranteed performances, bandwidth and latency. 3.2.4.7 Games Games is a server to people application, where one or more users can play with or against each other and/or a server. Strongly depending on the type of games, high interactivity may be required and delays may be unacceptable. Reduction of quality could be considered in general, but seems not to be a feature which can be used individually, according to the actual network situation. 3.2.4.8 Real-Time Internet Fax Facsimile will also be offered as a streaming service over the Internet. Real-Time Internet Fax is an application, which has strong requirements in the correctness of the © 1999 EURESCOM Participants in Project P913-GI page 19 (45)

Volume 1: Main Report Deliverable 1 received data. However, the real-time requirements (in terms of acceptable delay and jitter) are not high (terminals have lower communication speed as a fall back), but problems occur from the timer behaviour of the existing fax machines, based on T.30. In the communication scenario of T.38, a traditional fax machine (which has implemented T.30) is connected to an Internet Gateway (e.g., ISP). In this gateway, a mapping of the T.30 protocol elements is applied to the T.38 protocol elements. T.38 is the TCP/IP or UDP based protocol, which is running between the two Internet Gateways. Call establishment in T.38 is done by use of H.323. The receiving Gateway maps the T.38 protocol to the T.30 protocol, which is running between the receiving Gateway and the receiving traditional Fax machine. As the involved traditional fax- machines disconnect due to timers expiring problems may occur which are very specific to Fax. 3.2.4.9 IP Telephony IP Telephony integrates the local telephone networks with the Internet using specific voice to data gateways (which may or may not be H.323 compliant). Thus a long distance call can be split into two local calls and an Internet connection, which is transparent to end users. Such a phone service through Internet will be a major step towards integrated services on Internet. The central components of the IP telephony service are its gateways on Internet. These “boxes” act as gateways between the telephone network and the Internet. For this purpose, these gateways will have interfaces to both a computer network and the telephone network. To accomplish these functions an IP telephony gateway should support various telephone operations of detecting/generating telephone signals (ring, DTMF, etc. [6]), receiving/initiating phone calls, recording (digitising and compressing) or playing back audio signals, and monitoring the progress of a phone call. With the support of necessary hardware interfaces, the functions of gateways also includes: 1. Receive a local call or accept a connection from a remote server; 2. Identify the PIN of a local call and determine if to proceed the call or not; 3. Accept a phone number for remote dialling from a local call; 4. Look up the local directory for a remote server of a requested call; 5. Make a connection to a remote server; 6. Make a local phone call upon the request of a remote server; 7. Maintain full-duplex, real-time exchanges of voice packets via Internet; 8. Maintain information exchanges with Directory Servers; 9. Handle exceptional conditions, such as long delay or drop of voice packets; 10.Monitor quality of service and keep accounting information. 3.3 Constraints of real-time services 3.3.1 Real-time constraints In a switching network a transmission channel is allocated exclusively for that transmission. On the opposite an IP network consists of a unique resource shared by a set of computers. Therefore some real-time problems can be stressed due this structure. Actually a pure real-time transmission would require : • the data to be received at the same rate that they were sent page 20 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report • a unique route to carry the packets during the whole transmission time • minor losses of data • an constant availability of the resources 3.3.2 Internet specific issues The Internet technology involves many problems for real-time services. The real-time applications have to put up with transmission delay, network jitter, low end-to-end Internet bandwidth, a lack of reliability. Many characteristics of the Internet involve these problems : • The asynchronous transmission: there is every chance that 2 successive IP packets will not meet the same events during the transmission across the network. Therefore their transmission delay will probably differ. • The adaptative routing : in an obstructed network like the Internet, the packets are liable to take different routes. Therefore a packet that was sent sooner than another one can be received after. • An un-reliable network : the IP protocol does not assure that the emitted packet will be received by the destination. Loss rates commonly found in the Internet are 5%, which can cause major problems for real-time services. • The network jitter : as the availability of the resources in the Internet can not be predicted, several seconds obstruction can occur. Therefore, the impact on the average bit rate and on the transmission delay is very important for real-time services. 3.3.3 Quality requirements There are two definitions of ‘quality’ in terms of real-time services on the Internet. Subjective quality is the perceived quality of the media presentation from the point of view of the viewer. Objective quality is a measure of how much information arrives intact in a timely, constant manner. Objective and subjective quality can be closely related, but need not necessarily be that way. Many encoding algorithms have in-built mechanisms for coping with lost/corrupted packets as well as delayed packets and within limited conditions of network degradation there is no noticeable degradation in the subjective quality of the presentation. There are many techniques used to measure both the subjective and the objective quality of a received real-time stream. 3.3.3.1 The objective quality The issues associated with the objective quality of the received media presentation are: • Packet Loss. If the network is heavily congested, or if a node or link has failed, packets may be discarded, lost or corrupted. With real-time traffic, retransmitting the data is usually pointless, and these lost packets will usually degrade the subjective quality of the media presentation. In order to provide a quantitative measure of packet loss, it is necessary to know how many packets the server has sent. A simple comparison of how many packets were sent and how many were received will indicate the number that have been lost. By adding sequence numbers to packet headers, it is possible to establish how many packets have been lost without having to ask the server. © 1999 EURESCOM Participants in Project P913-GI page 21 (45)

Volume 1: Main Report Deliverable 1 • End-to-end packet delay. Packets may be excessively delayed if they are queued in routing buffers during transmission. This may cause packets to arrive out of sequence, and this could result in the media-presentation ‘freezing’ as it waits for the delayed packet to arrive, or distortion being added to the media presentation. In order to measure the peak and average delay of packets, time-stamping can be used. Information regarding the time at which each packet was transmitted can be added to the packet headers, and a similar process can be carried out at the receiver. Again, a simple comparison of when the packet was sent and when the packet was received will indicate the delay which the packet experienced is it passed through the network. In order for these measurements to be accurate, it is critical that both the transmitting and receiving host clocks are exactly in synchronism and stay that way. There are a number of ways of achieving this. GPS receivers at both source and destination can be used to synchronise both hosts with the same GPS system. This is a rather extreme measure to go to. An alternative is to use a common network clock. • Delay jitter. Delay jitter is the variance in delay of consecutive packets. For non- real time applications such as file transfer, it does not matter if three hundred packets are received in two seconds, and then none are received for another fifteen seconds. With real-time streams it is critical that packets are delivered as a constant stream to prevent drop-out of the audio stream or a jerky video presentation. For one-way streaming, buffering can be used to smooth out the effects of delay jitter. However, for multi-way streaming (such as web- conferencing) buffering cannot be used, as this will cause confusion amongst the communicating parties. In order to objectively measure the delay jitter in a particular stream, sequence numbers can be used. The sequence numbers indicate whether or not the packets are arriving in the same order as they were transmitted in, and a simple timer can be used to measure the delay between consecutive packets. Some statistics can then be compiled relating to the average and peak delay jitter. There are a number of tools available in both hardware and software which have been developed to allow monitoring of real-time communications traffic. However, since real-time Internet applications and services are relatively new technologies, there is not an exhaustive range of mature products available at this stage. 3.3.3.2 The subjective quality EURESCOM Projects P807-GI (JUPITER 2) & P905-PF (AQUAVIT) investigate the issues of subjective quality and usability of multimedia services. However it is already known that the subjective quality of real-time services involves some accurate requirements incompatible with the Internet technology. Therefore real-time applications have to put up with : • The transmission delay: this delay includes the emitting processing, the transmission time and the receiver processing. For full duplex applications, this delay should not exceed a few hundreds of ms. For simplex applications such as Audio or Video on Demand, it can be higher but should not exceed a few seconds. • The network jitter: for real-time audio-video services, the higher the average bit rate is, the more sensitive to the jitter the streams are. For example, for H.263 video at 64 Kbps and G.728 audio at 16 Kbps, the tolerable jitter is about 130 ms. For MPEG-1 audio and video streams at 1.5 Mbps, the tolerate jitter is about 10 ms. page 22 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report • The loss of data: the human perception ear is very sensitive to signal artefacts. Therefore, the loss of too much audio data will cause problems and moreover the audio requires a stream continuity. On the opposite, the human eye is less sensitive to such video artefacts and the loss of video packets will be supported more easily. A chance is that as the video requires higher bit rate than the audio, there more probability of video data being lost than audio data being lost at fixed bit rates. • The end-to-end bandwidth: when using the public Internet a user will not normally have a connection speed of more than a few tens of Kbps. Therefore the encoding techniques will have to provide high compression rates, and the quality will be very poor. However, for corporate networks or Intranets, higher bit rates can be targeted, and the quality will be better. 3.4 Protocol issues 3.4.1 UDP versus TCP1 TCP has many advantages: the transport is fully reliable, it is integrated with HTTP, it goes through the firewalls. However, the stream control mechanisms of TCP makes it non-suitable for real-time applications, because it wastes a lot of precious time. Moreover the congestion control of TCP (i.e. slow start, increasing packet rate until dropped, decreasing packet rates, and so on…) is not suited to deliver a continuous stream over IP. On the opposite, the UDP protocol is non reliable but it saves bandwidth. The UDP transmission, unlike TCP, makes only a "best effort" to deliver data, i.e. UDP transmission sends data blindly to a receiver without any feedback from the receiver (if a transmission error occurs, the packet is discarded). Nevertheless, UDP is the best suited protocol for real-time services because it is able to deliver a continuous stream with a little transmission error rate. On the other hand, the application layer is in charge of implementing mechanisms to emulate the reliability of the transmission (which is provided basically by TCP, but not by UDP). In a nutshell UDP is suitable for applications geared toward time performance rather than reliability. 3.4.2 Real-Time protocols 3.4.2.1 RTP/RTCP2 The Real-time Transport Protocol (RTP) provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. 1 See Annex A.2.2 & A.2.3 for definitions 2 See Annex A.3.1 for description © 1999 EURESCOM Participants in Project P913-GI page 23 (45)

Volume 1: Main Report Deliverable 1 3.4.2.2 RTSP1 The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP. 3.4.2.3 H. 3232 The H.323 standard provides a foundation for audio, video, and data communications across IP-based networks, including the Internet. By complying with H.323, multimedia products and applications from multiple vendors can interoperate, allowing users to communicate without concern for compatibility. H.323 will be the keystone for LAN-based products for consumer, business, entertainment, and professional applications. 3.4.2.4 T. 1203 T.120 is a set of standards which are specifying the Multi-Point conferencing applications over different types of networks (configuration of the Internet). A Multi- Point Control Service is responsible to handle the different communication channels between the multiple-users. The Generic Conference Control handles the different applications (including media) that are supported by T.120. Applications that are supported are Filetransfer, Still Image and application sharing. Normally, Audio Video is covered by H.320, H.323, but in parallel, T.130 series are offering also Audio Video Applications on top of T.120. The most popular realisation of T.120 (legacy mode) is Microsoft NetMeeting. 3.4.2.5 SIP4 The Session Initiation Protocol (SIP) is an application-layer control protocol that can establish, modify and terminate multimedia sessions or calls. These multimedia sessions include multimedia conferences, distance learning, Internet telephony and similar applications. SIP can invite both people and "robots", such as a media storage service. SIP can invite parties to both unicast and multicast sessions; the initiator does not necessarily have to be a member of the session to which it is inviting. Media and participants can be added to an existing session. 3.4.3 Transmission modes 3.4.3.1 Unicast data transmission Many current radio and television Internet broadcast applications use unicast data transmission for data distribution. In this case, connection-oriented stream transports are used to distribute data to each receiver individually. These applications duplicate 1 See Annex A.3.2 for description 2 See Annex A.4.1 for description 3 See Annex A.4.3 for description 4 See Annex A.3.5 for description page 24 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report the data they send to each receiver and use unicast transmission to each receiver. As a result of this duplication these applications are far from optimal due to the following reasons : • Network bandwidth is wasted, • They cannot scale to service increasing numbers of receivers, • They cannot distribute data in a timely manner, since the delivery to each host has to be serialised. 3.4.3.2 Multicast data transmission IP Multicast transmission provides the sending of data from a sender to multiple receivers, but unlike the IP Unicast, the number of identical copies that are sent is minimised. All receivers are configured as members of the same multicast group. The sender sends an IP packet to a multicast address, and lets the network forward a copy of the packet to each group of hosts. Multicast is not connection oriented: the sender sends data to multiple receivers over UDP. The IP Multicast protocol is implemented in the routers of a network, rather than in the server. The routers in the network automatically make a copy of the multicast packet for each destination receiver. Therefore IP Multicast routing requires special IP Multicast routers. All intermediate routers between the sender and receivers must be IP Multicast capable. 3.4.3.3 Broadcast data transmission Broadcast Data Transmission provides a one-to-all transmission where the source sends one copy of the message to all nodes whether they wish to receive it or not. This solution is inadequate for all but the smallest networks: end stations which are not interested in this traffic only receive it and then throw it away. 3.5 Best Effort versus Bandwidth Control 3.5.1 Best Effort services Due to the nature of best-effort Internet, it is obvious that the amount of bandwidth available to a particular best effort service may vary with respect to time (and location). For example, in Europe it is possible to listen to a clear, uninterrupted American radio webcast (using HTTP streaming) before about midday. After midday however, when the American public begins to log on to the Internet, the quality of the audio presentation degrades noticeably due to the fact that there are significantly more people asking for bandwidth from the network. Also, if the radio station is web- casting at only 128 kbit/s, it is almost impossible for a user to listen in to the web-cast if they are connected to the Internet at a much slower 28.8 kbit/s. The use of bandwidth adaptation can help alleviate both of the problems described above. Bandwidth adaptation dynamically adjusts the streaming rate of the media to suit the available bandwidth on the backbone network and in the local loop. In situations where the Internet is lightly loaded, the transmission rate and hence quality can be scaled up to the match the available bandwidth. Similarly, in situations when the Internet is heavily loaded the streaming rate of the media can be scaled down to suit the available bandwidth on the network. This should help to ensure that the media presentation is less susceptible to interruptions due to varying network conditions. © 1999 EURESCOM Participants in Project P913-GI page 25 (45)

Volume 1: Main Report Deliverable 1 There are a number of ways of achieving this bandwidth adaptation. Layered Coding and Transcoding are two techniques, and are discussed in Annex A.5. There are also some commercial implementations of the technology available from RealNetworks (SureStream) and Microsoft (Intelligent Streaming) amongst others. In order to implement bandwidth adaptation, it is necessary to evaluate the bandwidth which is available for a best effort streaming session. The simplest way of doing this is to compare the number of packets transmitted with the number of packets received. If packets are being lost, the transmission rate can then be reduced until equilibrium is achieved between the number of packets sent and received. If packets are not being lost, a test of available bandwidth can be performed by increasing the transmission rate and seeing if this higher rate can be sustained across a best effort network without equilibrium being broken. The RTCP protocol is used by a receiver to send packet reception information back to a transmitter. There are a number of other techniques which can be deployed, and it would be possible to write a complete document based solely on this topic. 3.5.2 Services with Bandwidth Control Unlike the best-effort Internet, the introduction of bandwidth control enables the Internet to become more like a broadcast network. In the scope of this Project bandwidth control considers all types of mechanisms which are able to maintain a kind of Quality of Service on the Internet. The goal is to emulate the behaviour of a real broadcast network with some characteristics such as bit-rate guarantee, minor loss, minor jitter, and so on. Several techniques for enabling the provision of QoS on the Internet are currently being developed in the Internet world, the most common of which is called IntServ and DiffServ. 3.5.2.1 Integrated services IETF IntServ Working Group has worked on the definition of classes of service aiming to define different levels of QOS guarantees; up to now ‘Controlled Load Services’ and ‘Guaranteed Services’ have been defined. IETF IntServ is mainly real- time applications oriented. We must distinguish non-real time applications which don’t really care about transmission delay variations (such applications wait for data before continuing to process it) from real time services which do not tolerate delay, insufficient bandwidth, delay variations or information loss problems. The two Classes of Services proposed by IETF IntServ working Group may be described briefly as follows: • Guaranteed services: provide assured level of Bandwidth related to bound delay parameters. Flow Control is based on token bucket mechanisms. • Controlled load services: reproduce behaviour of Best Effort Service under unloaded conditions. Percentage of delivered packets not exceeding minimum transmit delay as well as the percentage of packets successfully transmitted reach high values. IETF Integrated Services define the QoS Control services which provide the mechanisms to support the Quality of Service which is applied to the packets transmitted along a path in the network. page 26 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report RSVP protocol is a way to convey, from one network element to another (router, subnet, host) the applications’ requirements (real time application is delay bounded) and the QoS management information (close to a specific class of service). 3.5.2.2 Differentiated services IETF DiffServ Working Group has been launched in order to define ways to offer different Classes of Services depending on QoS and application requirements. Codepoints in IP Header (precedence bits) allow to associate Per Hop Behaviour to packets forwarding at each node of the network.. Up to now, 2 PHB groups have been defined : • Assured Forwarding (AF) PHB Group: IP packets are forwarded within the Internet with high probability as long as the subscribed information rate (profile) is not overpassed. • Expedited Forwarding (EF) PHB Group: The EF PHB Group is designed for end to end services to assure low loss, latency, and jitter, as well as to provide assured bandwidth. In that way such a PHB group leads to high constraint on queues: if no queues arise on an aggregate node in the network, maximum arrival rates will be lower than minimum departure rates. 3.5.2.3 Queuing techniques Real Time applications and Services may require some resources to be reserved. Once the resources are reserved, it is the duty of the Internet routers to ensure that these resources are actually provided. This requires the implementation of queuing mechanisms which can prioritise packets and/or streams for processing. Queuing techniques are network level mechanisms allowing the mapping of QoS control features towards the network. They are implemented in network elements to face and deal with traffic congestion as well as to manage traffic flow priorities. Queuing techniques will help to classify packet flows depending on the Class of service they refer to. Most of the time they are closely linked to decision mechanisms to carry out the classification of packets. There are a number of queuing mechanisms which can be used. The most relevant are detailed below. • First-in-First-out (FIFO) Packets from all sources are placed into one queue in the same order in which they arrive at the router inputs and are processed and forwarded in this same order. For real-time streams which have resource reservation, this mechanism is useless as there is no way of giving priority to packets which have made reservations. A high bit-rate flow can place a large number of packets into the queue and cause extra delay to other flows which transmit fewer packets. • Priority Queuing (PQ) Priority Queuing gives strict priority to important traffic, with the level of importance specified by the protocol type of the incoming packets, the interface on which they are arriving, the packet size or the source/destination address of the packet. Four separate queues are defined in PQ – High priority, Medium Priority, Normal Priority and Low Priority. Each incoming packet is placed in one of these queues depending on its specified priority level. Packets which are unspecified are placed in the Normal queue. The higher-order priority queues are given preferential treatment over lower-order © 1999 EURESCOM Participants in Project P913-GI page 27 (45)

Volume 1: Main Report Deliverable 1 priority queues. This can cause lower-order queues to be subject to very high delays and increased jitter. This can be controlled by rate-limiting high priority traffic flows to ensure it doesn’t overwhelm the router and consume all it’s resources. • Class Based Queuing (CBQ) CBQ is a flexible queuing mechanism which classifies user traffic and assigns bandwidth characteristics to each traffic class. CBQ is applied at the IP layer, and as such is independent of the technologies used in layers 1 and two. Thus, CBQ can offer consistent Class of Service over any Layer 2 technology. In addition, CBQ is already compatible with routers deployed in the network. When packets enter the router, they are classified and passed directly onto the appropriate output port if the allocated bandwidth of the stream is not being fully used. If the allocated bandwidth is being fully used, then each traffic class can be authorised to ‘borrow’ capacity from other streams which have idle capacity at that point in time. page 28 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report • Fair Queuing (FQ) Fair Queuing creates one queue for each data flow and services them in a round-robin fashion. This means that all queues get equal treatment and all queues are allowed to transmit one packet per cycle. Thus flows which send many packets will end up with long queues and long delays while other flows are not affected. This system does not allow proper prioritisation and may in fact be detrimental to high bit-rate real time applications such as live video streaming. • Bit-round Fair Queuing (BRFQ) This algorithm attempts to give equal treatment to all flows regardless of the size of the packets in the queue. The algorithm creates one queue per flow as in Fair Queuing, but attempts to ensure that the effective bit-rate allocated to each source is approximately equal. Thus, flows which consist of few large packets are not given priority over flows which have many small packets. • Weighted Fair Queuing (WFQ) This is similar to BRFQ with the exception that instead of giving all queues equal effective bit-rates, different flows can be given different shares of the available capacity. Each queue is assigned a weighting and the bit rate allocated to each flow is proportional to the weighting assigned to it. By setting the weights to be proportional to the reserved bandwidth of the flow, a suitable queuing mechanism is achieved. • Weighted Random Early Detection (WRED) This is a congestion avoidance mechanism which aims to limit the queue sizes of particular flows by indicating to the transmitting hosts that a queue is developing and that they should slow down or cease transmission temporarily while congestion is relieved. This takes advantage of the TCP ‘exponential back-off’ congestion control mechanism. Weighted Random Early Detection attempts to avoid congestion before it occurs. Packets are dropped randomly before congestion occurs, and TCP at the end hosts will automatically decrease the transmission rate. WRED selectively drops the packets based on the IP precedence of the packets. The higher the packets precedence, the lower are the chances of it being discarded. Thus, higher-priority traffic is delivered with a higher probability than lower-priority traffic. © 1999 EURESCOM Participants in Project P913-GI page 29 (45)

Deliverable 1 Volume 1: Main Report 4 Reviews on items related to the Internet real-time services 4.1 Standards for Real Time Internet Services1 There are a number of standardisation bodies which are concerned with developing and implementing standards for real-time services on the Internet, including the International Telecommunications Union (ITU), the Internet Engineering Task Force (IETF), the European Telecommunications Standards Institute (ETSI) among many others. There are a very large number of transport and signalling protocols relevant to real- time services, including Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), HyperText Transfer Protocol (HTTP), Real Time Transport Protocol/Real Time Control Protocol (RTP/RTCP), Real Time Streaming Protocol (RTSP) and Resource Reservation Protocol (RSVP). The choice of which protocols are used can have a significant impact on how well the real-time services will perform. For example, the behaviour of TCP renders it unsuitable for many real time services, while RTP over UDP is very well suited to such services and applications. Since most users of the Internet are connected at relatively low data rates, it is critical that any real-time services must reduce the required bandwidth by as high a factor as possible without excessively degrading quality. Thus, there are many standards which address the issue of encoding and data compression. One of the most important standards in this area is H.323 which specifies a number of codecs for audio and video. The MPEG series of standards also address the issues of compressing audio and video data to different data rates, depending upon the quality of media required for the application. T.120 is a standard which addresses the issues associated with the sharing of documents, DVEs and games over communications networks in real-time. It is unlikely that all users who wish to view a real-time audio/video stream or participate in an online conversational session will be connected to the Internet at the same data rate. Traditionally this would have meant that the data would have to be streamed at the lowest data rate of all the users. However, modern coding techniques such as Layered Coding and Transcoding have enabled dynamic bandwidth adaptation to take place, enabling users to receive data at which ever rate they are capable of, meaning that people who are connected at higher data rates will view higher quality media presentations relative to those who are connected at lower rates. 4.2 Tools and Commercial Products2 There are a great number of real-time tools and applications available for the Internet, many of which are available as freeware. These tools and applications can generally be divided up into two groups: Audio/Video Streaming Applications and Telephony/ Conferencing Applications. In the area of Audio/Visual Streaming tools and applications, there is a very aggressive marketing war being waged between Microsoft and RealNetworks. Microsoft has developed their NetShow server which can stream video and audio to a Microsoft MediaPlayer client on the receiving host. The MediaPlayer client comes 1 Please refer to Annex A for more detailed information 2 Please refer to Annex B for more detailed information © 1999 EURESCOM Participants in Project P913-GI page 31 (45)

Volume 1: Main Report Deliverable 1 bundled with the Windows operating system, and the NetShow server can be purchased from Microsoft. RealNetworks offering, RealSystem G2 is a cross- platform audio-video solution built upon the industry standard protocol for streaming media, RTSP and around the SMIL (Synchronised Multimedia Integration Language) file format. The RealPlayer software for viewing media is available as freeware, and the server software is available for purchase from RealNetworks. Both NetShow and RealSystem are capable of bandwidth adaptation. There are a number of other vendors who participate actively in this market including Apple who have added streaming functionality to their QuickTime software and Cisco who offer their IP/TV product as a complete streaming and content-management solution for corporate networks. In the area of Telephony/Conferencing, there are many applications available. Perhaps the most widely used of these is Microsoft’s NetMeeting. This is available as freeware and allows real-time collaboration over the Internet/Intranet. It allows both audio and video communications as well as document sharing. WhitePine Software has developed a number of tools and applications, including Cu-SeeMe – a multicast- capable conferencing tool which allows video, audio and text conferencing. The most recent version at the time of writing claims to be fully H.323 compatible. WhitePine also offer MeetingPoint tools which manage virtual conferences. Other telephony/conferencing tools include VocalTec’s Internet Phone, VDO Phone, MediaRing Talk Net2Phone, Netscape’s CoolTalk, Intel’s Internet Video Phone. 4.3 Market Trends1 Streaming video and audio over the Internet and using virtual conferencing has been becoming increasingly popular over the last few years, and this trend is likely to continue for the foreseeable future. Almost all the major players in the Internet market are paying close attention to the technologies and market demands for real-time Internet services. Microsoft and RealNetworks have been engaged in an aggressive battle for the largest share of the video/audio streaming market, and there are several other players who have much to offer, including Apple and Cisco. Microsoft is also competing with WhitePine’s CU-SeeMe in the market for conversational applications. While the competition between the companies which offer the underlying technology is continuing to heat up, a similar competition is emerging between companies who aim to provide the actual content which will be streamed. In the US, the ABC, Fox and CNN corporations are beginning to utilise the Internet as a new medium of giving the public access to it’s programmes. Broadcast.com, Mr Showbiz , MSNBC and Disney are also getting involved. Network operators are also paying serious attention to developments, as bandwidth requirements are set to increase due to the increase in multimedia traffic being carried, and more sophisticated routers will have to be deployed to allow bandwidth control and multicasting. For Internet Service Providers, the ability to provide streaming media content can serve as an important value-add that can win new customers and justify higher subscription levels. There is a great deal of interplay between network operators, service providers, content providers and application vendors. Customers will require more advanced services like media streaming to the desktop or virtual conferences, which will require the service provider to have the necessary infrastructure and connectivity, which in turn requires the network operator to have the appropriate technology and capacity deployed. 1 Please refer to Annex C for more detailed information page 32 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report 5 Analysis of the road-map The purpose of this section is to analyse the road-map for current real-time services, underlying the problems involved and the implications in the Project for Task 3 & Task 4. 5.1 Main constraints for current real-time services The various real-time services have different requirements with respect to the Internet technology. It is important to note that only the lower-cost solutions will be considered for each application in this description. Obviously with more expensive products and access, more sophisticated features can be obtained and deployed. The following table sums up the major characteristics for the main real-time services. NON-INTERACTIVE CHARACTERISTICS STREAMING SERVICES Audio Video Broadcasting • Reception at constant rate • Delay well supported in case of sufficient buffering • No reduction of quality allowed (integrity of the data required) Audio Video on Demand • Small delay well supported • Reduction of quality well supported (possibility to use a mechanism to reduce the amount of data) Data type streaming • Delay well supported (Internet Fax) • Reduction of quality not supported (integrity of the data required) INTERACTIVE CHARACTERISTICS STREAMING SERVICES Audio Video on Demand • Delay not supported because of VCR facilities • Reduction of quality well supported (possibility to use a mechanism to reduce the amount of data) Games • Delay badly supported because of the interactivity • No reduction of quality allowed News on Demand • Delay badly supported because of the interactivity • Reduction of quality well supported (integrity of the data required) CONVERSATIONAL CHARACTERISTICS SERVICES AudioTelephony • Delays not acceptable for full duplex applications • Small reduction of audio quality acceptable (can put up with minor losses of data) VideoTelephony • Delays not acceptable for full duplex applications • Audio and Video need to be well synchronised • Reduction of video quality more acceptable than reduction of audio quality Conferencing Different type of information’s : the requirements differ from one media to another : • For Audio & Video: delays not acceptable, reduction of quality acceptable • For File transfer: delay well supported, reduction of quality not acceptable (integrity of the data required) • For SlideCast: delay acceptable © 1999 EURESCOM Participants in Project P913-GI page 33 (45)

Volume 1: Main Report Deliverable 1 On-line Multipart Games • Delay badly supported because of the interactivity • No reduction of quality allowed Internet Chat • Small delay well supported • Reduction of quality not supported (integrity of the data required) 5.2 Main issues involved by the Internet Technology This section summarises the main problems related to Internet technology. These six items are the key-elements to be considered regarding real-time services on the Internet. 5.2.1 The packet loss The loss of data in the Internet can have different consequences depending on the kind of media to be streamed. However, it always brings about a degradation of the subjective quality. For audio it causes interruption in the sound if too many frames are missing. For video it causes some artefacts such as freezing frames, blocking effects or loss of resolution. For other data such as slides, files, text, it causes missing parts which might be difficult to be interpolated by the human mind. Nevertheless, the applications have to put up with these losses of data and must have a strategy to reconstruct the missing parts. 5.2.2 The end-to-end delay The end-to-end delay in the Internet includes the processing time at the transmitter, the transmission time and the processing time at the receiver. Therefore, it sets low interactivity, which is unacceptable for full duplex applications. This delay must be quantified: the delay tolerance will differ from one application to another. It should not exceed a few hundred of ms for conversational applications to maintain spontaneity, but can be higher for streaming applications with VCR facilities. Moreover, it can lead to a media presentation being frozen or distorted. 5.2.3 The network jitter The network jitter in the Internet requires a buffering mechanism to be imposed at the client side, in order to absorb this jitter. Moreover it sets non-constant rate delivery. This can cause drop-out audio or jerky video, and the different media have to be re- synchronised. At least, as for the end-to-end delay, it sets low interactivity, which is unacceptable for full duplex applications. 5.2.4 The end-to-end bandwidth If the end-to-end bandwidth in the Internet is too low it can result in a poor level of subjective quality. Due to the nature of the public Internet, high compression rates are deployed to restrict the bit-rate of a particular media stream to a few tens of Kbps and the quality can be very poor. Different parts of the Internet must be considered to take into account the end-to-end bandwidth: page 34 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report • The access: it can have different characteristics from traditional dial-up 28.8 Kbps modem to cable. It implies the values of the main encoding rates. • The server gateway: it is limited in amount of data which can be transmitted simultaneously. • The capacity of the backbone: the available bandwidth depends on the geographical distance and the time of the day of the connection. For example it is easier to listen to audio streaming from Europe than from America, especially in the afternoon. While the first 2 bullets can be configured, the last one is independent and the service provider has to put up with it. 5.2.5 The packet size Internet routers must examine the headers of IP packets which arrive in its buffers in order to make decisions as to where to forward the packet. Thus it can easily be seen that the amount of processing the router is required to do can be minimised by reducing the number of packets which arrive in the routers buffers. Routers are loaded, not by the amount of data they have to route, but by the number of packets they have to process and forward. Large data packets have high data transfer efficiencies. Conversely small packets have very poor data transfer efficiency! Thus packets which have large amounts of data in the packet payload can enable significantly higher bit rates to be achieved than would normally be expected for a given media stream. Packet size also has an impact on the routers buffer, congestion and in turn throughput delays. Some routers can be configured to only forward packets of a particular size and reject others. It is important that application packet sizes fall within the margins defined as allowable by the network routers. So why not make packets as large as possible? There are a number of reasons why this may not be the best approach with interactive real-time Internet applications. Large packets take longer to build and process than smaller ones! The loss of larger packets can have a more serious effect on the subjective quality of the media presentation, since there is the potential to lose a greater amount of information for a given rate of packet loss. From the application and client point of view, each packet requires buffering and processing. In most client operating systems, there is no way of characterising and scheduling when a packet is to be processed. It is therefore possible to imagine a situation where a small audio packet requires processing but is delayed behind a large video packet. The delay could render the audio packet so badly jittered, that the application regards the packet as lost. In this case small packets are preferable to large ones. 5.2.6 The network topology Although some physical network topologies are better suited for Real-time Applications than others, that is not something to be considered at this level, since between the ends of an Internet connection there is no control over which topologies may be involved. So, the important issue here is the ability to somehow provide a means of guaranteeing a pre-determined Quality-of-Service across the network path involved in providing an Internet connection. The overall QoS will obviously be no better than the worst-case QoS found along the transmission path. © 1999 EURESCOM Participants in Project P913-GI page 35 (45)

Volume 1: Main Report Deliverable 1 RSVP is generally used as the protocol that handles the reservation process over IP networks, but the necessary interworking between RSVP and other QoS provision mechanisms - e.g. those native of ATM - must be assured. 5.2.7 Acceptable level of quality The aims of P913-GI are to establish the configurations and scenarios which enable real-time services to be implemented successfully on the Internet. The tests and experiments that will be carried out will use packet delay, delay jitter and packet loss as the merits which determine the performance of the service/application. In order for the results of these tests and experiments to be interpreted objectively, it is important to set some theoretical values for packet delay, delay jitter and packet loss so that the actual values obtained from the tests can be compared with the theoretical values. In this way, it shall be possible to say whether a particular service/application performs sufficiently well in any given configuration. It is by no means straight forward to produce a set of theoretical results for packet delay, delay jitter and packet loss for real-time services. Very much research effort has been exerted into the subject, and there is no clear-cut definitive answer. There are a very large number of variables which affect the perceived subjective quality of the person using the real-time service. As such, the theoretical values listed below are not necessarily applicable to every situation. For example, the amount of packet loss that can be tolerated is highly dependent on the encoding/compression algorithms deployed, the nature of the original data and the ability of the application to perform error recovery. However, in the ETSI Project "Telecommunications and Internet Protocol Harmonisation Over Network" (TIPHON), a technical report from WG5 has been published discussing "General aspects of QoS" for IP Telephony. Four classes of Degradation Categories have been defined according to their packet loss and delay jitter: • Perfect is for 0% of packet loss and 0 ms of peak jitter • Good is for 3% of packet loss and 75 ms of peak jitter • Medium is for 15% of packet loss and 125 ms of peak jitter • Poor is for 25% of packet loss and 225 ms of peak jitter By doing a similar classification for real-time services in P913-GI, we have considered that such parameters may be suitable for our situation. Therefore it has been agreed that we decide upon some arbitrary values for the delay, jitter and data loss variables. Once tests are completed, actual results could be compared with the theoretical limits to determine how good or bad they are, and how much of an improvement bandwidth control gives us. In that way, the tables below detail some suggested theoretical values for both streaming and conversational applications. Theoretical Values For Online Conversational Services Typical Expected Absolute Maximum Acceptable Packet Delay 150 ms 350 ms Delay Jitter 75 ms 125 ms Packet Loss 2-3 % 10 % page 36 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report Theoretical Values For Online Streaming Services Typical Expected Absolute Maximum Acceptable Packet Delay 2-3 seconds 8 seconds Delay Jitter 1 second 3-4 seconds Packet Loss 2-4 % 10 % 5.3 Feasibility in best effort Internet versus bandwidth control network This section highlights the current services which can put up with the best effort Internet, and those which explicitly need bandwidth control. It is a form of conclusion to the crossing of sections 5.1 & 5.2. 5.3.1 Services currently working under Best Effort Internet These kinds of services can put up with the packet loss, the end-to-end delay, the network jitter and the end-to-end bandwidth. They use application features to maintain an acceptable quality of service under best effort conditions. Therefore delays and reduction of quality are well supported. SERVICES PRODUCTS & TOOLS CHARACTERISTICS Audio Video • Real Video, Real Audio • Low bit rate encoding Broadcasting • Microsoft Netshow services • Low subjective quality • VDO live • Buffering compulsory Audio Video on Demand • Real Video, Real Audio • Low bit rate encoding • Microsoft Netshow services • Low subjective quality • VDO live • Buffering compulsory 5.3.2 Services currently using Bandwidth Adaptation These kinds of services can put up with the packet loss and the lack of bandwidth, but the end-to-end delay and the network jitter are not acceptable. They use mechanisms to adapt to the available bandwidth and maintain the quality of service requested. Therefore the reduction of quality is well supported but too much delay is badly supported. SERVICES PRODUCTS & TOOLS CHARACTERISTICS Audio Video on Demand • Real Video, Real Audio • “Sure stream” • Microsoft Netshow services technique • “Intelligent streaming technology” • layered coding • RTP/RTCP Audio Telephony • VocalTec • RTP/RTCP • Webphone VideoTelephony • Microsoft NetMeeting • RTP/RTCP • Vic/Rat • RTIP Data streaming • Included in multiparty conferencing tools © 1999 EURESCOM Participants in Project P913-GI page 37 (45)

Volume 1: Main Report Deliverable 1 5.3.3 Services getting benefit from Bandwidth Control These kinds of services could put up with a degree of packet loss, end-to-end delay, network jitter and restricted end-to-end bandwidth, but can use bandwidth control mechanisms to improve the quality of service. Therefore the issues of the Internet technology as described in section 6.2 are not acceptable. Depending on the targeted quality of service, the reduction of quality due to the delay is more or less badly supported. SERVICES PRODUCTS & TOOLS CHARACTERISTICS Games • Quake I & II • High interactivity Conferencing • Microsoft NetMeeting v2.11 • Full duplex application • WhitePine’s Meeting Point • Different kind of media High quality AV • Cisco IP/TV • Need high bandwidth broadcasting • Xing Tech. Streamworks resources High quality AV on • Real Video with MPEG-1 Demand • Microsoft Netshow Theater 5.3.4 Services currently using Bandwidth Control at the application level For these types of services, the packet loss, the end-to-end delay, the network jitter and the end-to-end bandwidth are not acceptable. Bandwidth control mechanisms have been implemented at the application level to improve the quality of service. Depending on the targeted quality of service, the reduction of quality due to the delay is more or less badly supported. SERVICES PRODUCTS & TOOLS CHARACTERISTICS High quality • Microsoft NetMeeting included • RSVP Conferencing with Windows 2000 • VIC 5.4 Proposed access scenarios This section proposes the different configurations and test scenarios to be analysed in the Project. Different types of access are possible to carry out the tests, depending on the kind of network connectivity available. 5.4.1 Access scenarios for best-effort Internet The network to be considered in the Project will be the public Internet, without any assumption about the end-to-end physical networks and gateways used to carry the data. Consistent results will be obtained if best effort tests are performed on a network close to the live Internet, taking into account the congestion issues. In that way, several access scenarios will be explored : • Access through a traditional modem via PSTN : 28.8, 56 Kbit/s • Access through ISDN dial-in account : 64, 128, 256, 384 Kbit/s (N x ISDN) • The Project will also explore the feasibility of access through ADSL • Access through cable will not be explored page 38 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report 5.4.2 Access scenarios for a network with bandwidth control The scope of this Project shall be limited to networks, which will provide the necessary bandwidth control. Such an environment will facilitate bandwidth reservation and offer different QoS levels using appropriate mechanisms. Therefore the main access should be provided via a corporate LAN, up to 2 Mbit/s. In that way, the Project will have to give recommendations on the following items: • The bandwidth control in the access network: tools that are able to negotiate bandwidth with the ISP over the access network (using RSVP with IntServ for example), mechanisms deployed in the nodes of the network to properly forward RSVP Reservations up to the other gateway through the network • The bandwidth control in the gateway: studying traffic management control mechanisms and the associated queuing techniques currently existing or already implemented. In short terms, it means describing flow classification using QoS network level techniques • Offering different classes of services on the network (see previous limitations on the network definition): investigating possible implementations of differentiated services (RSVP and DiffServ / IETF) Note: special attention must be kept to firewall and security issues. 5.5 Implications and prioritisation for Task 3 & Task 4 of the Project This section describes the areas selected for the Project and the areas of less interest. 5.5.1 Areas of less interest According to the previous sections of this document, the planned tasks of the Project will not take into account real-time services such as : • Fax over IP and other data type of streaming: these applications are of minor interest as regards with the introduction of bandwidth control. Moreover, most of them are already included in multiparty conferencing tools. • IP Telephony: this service is already explored by many other Projects. • Push services, Internet Chat: they are not strictly real-time services according to the definition in Section 2. • Games: as far as games like chess are played over the Internet, there are no real- time aspects to be analysed. Other types of games, like multi-partner adventure games, have real-time requirements, but the amount of data to be transferred is extremely small so that these applications are not sufficiently significant to be considered by the Project. Moreover, the Project will not consider bandwidth control mechanisms on the public Internet network, because it is obviously difficult to have any end-to-end control over the resources of this network at the present time. 5.5.2 Areas to focus on Considering the goal of the Project and the information provided in the previous sections, the Project will focus on the following items : © 1999 EURESCOM Participants in Project P913-GI page 39 (45)

Volume 1: Main Report Deliverable 1 • Access from 28.8 Kbit/s up to 2 Mbit/s, using mainly ISDN dial-in account, but also dial-up access with a traditional modem via PSTN and ADSL access, to explore a larger range of configurations currently used in the Internet area. • High-bandwidth applications to be tested in networks such as LAN, private networks, end-to-end ATM networks, ADSL, and so on. In that case, as the main issues for best effort Internet services are automatically resolved by the available bandwidth, these applications will be explored mainly for bandwidth control experiments. Therefore QoS based-tests will be performed on a corporate network or any other LAN. • The Project will focus on the 2 following types of services: conversational services and streaming services, whether interactive or not. More generally, the Project will consider: • The issues which should be addressed in order to move from best effort Internet to the introduction of some bandwidth control. • The improvement of quality for current real-time applications, even if they already work properly under best effort Internet. • The real-time services which absolutely need bandwidth control. • The implications for the selected applications of introducing bandwidth control mechanisms in the 3 fields: the access network, the Internet itself and the gateways. 5.6 Application scenarios selected by the Project This section describes the applications to be analysed in detail in the Project, for both conversational and streaming services. 5.6.1 Conversational aspects Concerning the conversational applications, the selected scenarios are the following. 5.6.1.1 Microsoft NetMeeting1 Microsoft NetMeeting is the most widely used multipoint conferencing tool with data sharing in the Internet as in corporate Intranet. Moreover it explores a range of rates selected by the Project, from 28.8 Kbit/s to 256 Kbit/s. At last it supports H.323 communications and uses standard features. Therefore, on one hand these tools need to be analysed in Project as regards with best effort tests. On the other hand, the future version of NetMeeting integrated in Windows 2000, will include some bandwidth control mechanisms, and thus it will be used to carry out QoS-based tests. 5.6.1.2 CU-SeeMe2 CU-SeeMe is one of the most popular multipoint videoconferencing platform, considered as an alternative to Microsoft tool. Even if it does not support data sharing and if it is not H.323 compliant, this product must be considered on the scope of the Project. The range goes from 28.8 Kbit/s to 64 Kbit/s, and is most suitable for best effort Internet tests. 1 See Annex B.2.1 for description about this product 2 See Annex B.2.2 for description about this product page 40 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report 5.6.1.3 One hardware oriented application1 It has also been decided to include one hardware oriented configuration to test conversational services. The pro-arguments are the improved quality compared to software tools, the independence from the CPU host machine. Moreover, this kind of platform is more professional, and the Project should explore the widest possible range of products. However, the choice of this tool has not been decided at the moment of the writing. 5.6.1.4 VIC/VAT2 This product is primarily intended as a multiparty conferencing application. It consist of a set tools used for video conferencing over the Internet, and supports IP Multicast. It is designed with a flexible and extensible architecture to support heterogeneous environments and configurations: for low bandwidth environments like the Internet, aggressive low bit-rate coding can be carried out in software, and for high bandwidth settings, multi-megabit streams can be sourced using hardware assisted compression. It has been chosen in the Project as it includes bandwidth control mechanisms at the application level, and in that way it will be used to perform QoS-based tests. 5.6.2 Streaming aspects Concerning the streaming applications, the selected scenarios are the following. 5.6.2.1 DT/MTG Music on demand3 This service, provided by Deutsche Telekom, streams audio from a server to the client PC, mainly through ISDN access. It offers a huge database where the clients can select any kind of music listed by title name, CD-name, interpreter/artist and composer. The service includes a search engine. The clients can download a free pre- listening to evaluate the music before downloading and paying for the full song. The music tracks are stored in MPEG 1-Layer 3 (MP3) format. This product has been chosen in the scope of the Project because it is the only tool on which we have the complete control, as it is provided by one of the partners. It will be tested both under best effort and bandwidth control conditions. 5.6.2.2 Real Video4 This product is the most popular audio and video streaming application world-wide. First known as real audio service, it now uses scaleable video codecs for all bit rates, but mainly from 28.8 Kbit/s to 256 Kbit/s (it is optimised for Internet connection speeds of 28.8 Kbps, 56 Kbps and 112 Kbps). If MPEG-1 features are installed, it can also access higher bandwidth networks. This tool will be one of the primary products to be tested in the Project, mainly under best effort Internet conditions including bandwidth adaptation. 1 See Annex B.2.11 for description about conversational hardware platforms 2 See Annex B.2.9 for description about this product 3 See Annex B.1.7 for description about this product 4 See Annex B.1.1 for description about this product © 1999 EURESCOM Participants in Project P913-GI page 41 (45)

Volume 1: Main Report Deliverable 1 5.6.2.3 Microsoft Netshow services1 This tool is the alternative to Real Video products. Its features are almost the same, and a lot of studies try to compare the two products. In the scope of the Project it is essential to analyse them both, especially for best effort Internet tests including bandwidth adaptation. Moreover, with Microsoft Netshow Theater, high bandwidth features can be analysed, maybe for the introduction of some bandwidth control. 5.6.2.4 Cisco IP/TV2 This application, originally developed by Precept Software, is aimed at delivering business communications to enterprise corporate networks. It can be tested for high bandwidth streaming services, mainly because RSVP proposals have been carried out by Precept Software. Moreover it is backed by Cisco's superior service and support. In the scope of the Project, this solution will be tested in Task 4 under bandwidth control conditions. 1 See Annex B.1.2 for description about this product 2 See Annex B.1.6 for description about this product page 42 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report 6 Conclusions The first aim of this Deliverable was to provide a state-of-the-art analysis that identifies the significant issues in the area of real-time services over the Internet: Internet technology, issues regarding real-time services, a review of standards and products, the market trends. The main document consists of the road-map which discusses the Internet technology, the real-time services and the analysis topics. The more detailed reviews are included in the technical Annex. Therefore the main conclusions that have been drawn are: • The Internet, a network of networks, has not been designed primarily to support real-time services requirements. Therefore, these applications have to put up with the Internet technology issues, and both the standardisation bodies and the product manufacturers in the area are trying to provide new solutions which meet the stringent requirements of real-time services. • Most of the new standardisation efforts are targeted towards developing standards for best effort services, including mechanisms for bandwidth adaptation, and standards to introduce bandwidth provision on existing networks for various levels of QoS. • The product manufacturers have very similar strategies. They intend to use the existing technology and to introduce new features to improve the quality of services. In the software area, the two major companies in the market are Microsoft and RealNetworks, and the main actor in the area of Internet technology is Cisco. Today, whereas most of these companies promote bandwidth control mechanisms at the gateway and the access levels, only few actors tend to include these features at the application level. • Finally, the market trends lead to similar conclusions: as the Internet grows in global size and bandwidth, and as computer technology increases in speed and drops in price, real-time applications over Internet will become increasingly more feasible. There is no doubt that the use of real-time applications over the Internet will become more widespread. On the other hand, the main technology issue today seems to be the demand for bandwidth, and the demand for QoS also becomes an important key-factor. As the provision of this Deliverable is the first stage in the Project, its second goal is to explain the purpose of the application scenarios selected for both tests under best effort conditions and tests using bandwidth control mechanisms. Therefore, the results of this road-map analysis lead to the following recommendations for Task 3 and Task 4: • As a result of having compared real-time services constraints with Internet technology issues, the Project will focus on two major classes of real-time services: the audio-video streaming applications and the conversational applications. • For each of them, tests will be performed, first to record results about the feasibility of real-time services over the best effort Internet, and then to make recommendations about the best way of introducing bandwidth control mechanisms. • Several access technologies have been selected to carry out these tests. For best effort tests, the main access is the ISDN dial-in account (mainly 128 Kbps, but also 64, 256, 384 Kbps), completed with access through a traditional modem via © 1999 EURESCOM Participants in Project P913-GI page 43 (45)

Volume 1: Main Report Deliverable 1 PSTN (28.8, 56 Kbps), ADSL and LAN access (up to 2Mbps). Concerning tests with bandwidth provision, the Project will be limited to an environment in which bandwidth reservation can be established and different QoS levels offered using appropriate mechanisms. A corporate network is the only one suitable for providing the necessary end-to-end control. • The Project will focus on the most popular products able to explore the range of bit rates selected (from 28.8 Kbps to 2Mbps). Thus, for conversational aspects the products selected are Microsoft NetMeeting, Cu-SeeMe, Vic/Vat, plus one hardware platform. For streaming applications, it will be DT/MTG MusicOnDemand, Real Video, Microsoft Netshow services and Cisco IP/TV. page 44 (45) © 1999 EURESCOM Participants in Project P913-GI

Deliverable 1 Volume 1: Main Report References [1] "Data Communications, Computer Networks and Open Systems", Fred Halsall [2] "Data Systems: Lecture Notes", Dr Saleem Bhatti, University of London [3] "H.323 Primer", http://gw.databeam.com/h323/h323primer.html [4] "H.323 Tutorial", http://www.webproforum.com/trillium/full.htm [5] "T.120 Primer", http://gw.databeam.com/ccts/t120primer.html [6] “IETF/RFC standards”, http://www.ietf.org/rfc [7] “G-series, H-series, T-series standards”, http://www.itu.int © 1999 EURESCOM Participants in Project P913-GI page 45 (45)

D1Vol1.doc

by Ronny72

Accessibility

Upload Details

Usage Rights

Statistics

D1Vol1.doc Document Transcript

D1Vol1.doc

by Ronny72

Accessibility

Upload Details

Usage Rights

Statistics

D1Vol1.doc Document Transcript

Let LinkedIn power your SlideShare experience

Let LinkedIn power your SlideShare experience

Customize SlideShare content based on your interests

Keep up to date when your LinkedIn contacts post on SlideShare