D1Vol2.doc.doc

1,390 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,390
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

D1Vol2.doc.doc

  1. 1. Project P913-GI Real-time services on the Internet Deliverable 1 Road-map for current real-time services over the Internet Volume 2 of 2: Annexes 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
  2. 2. 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
  3. 3. Deliverable 1 Volume 2: Annexes 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 multi- party 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 (viii)
  4. 4. Volume 2: Annexes Deliverable 1 page ii (viii) © 1999 EURESCOM Participants in Project P913-GI
  5. 5. Deliverable 1 Volume 2: Annexes List of Authors Kevin Wilson BT Andrew Auchterlonie Deutsche Telekom Hans-Detlef Schulz Deutsche Telekom David Girault France Télécom Stephane Pallavicini France Télécom João Paulo Firmeza Portugal Telecom © 1999 EURESCOM Participants in Project P913-GI page iii (viii)
  6. 6. Volume 2: Annexes Deliverable 1 Table of Contents PREFACE...........................................................................................................I LIST OF AUTHORS......................................................................................III TABLE OF CONTENTS................................................................................IV ABBREVIATIONS......................................................................................VIII ANNEX A: REVIEW OF INTERNET STANDARDS..................................1 A.1 Standardisation Bodies..............................................................................1 A.1.1 International Telecommunications Union (ITU)................................1 A.1.2 The Internet Engineering Task Force (IETF)....................................1 A.1.3 European Telecommunications Standards Institute (ETSI)...............1 A.1.4 International Multimedia Teleconferencing Consortium (IMTC)......1 A.1.5 International Standardisation Organisation (ISO) & ISO/MPEG.....1 A.1.6 DAVIC.................................................................................................2 A.2 The Internet Suite of Protocols.................................................................2 A.2.1 Internet Protocol (IP) ........................................................................2 A.2.2 Transmission Control Protocol (TCP)...............................................5 A.2.3 User Datagram Protocol (UDP)........................................................6 A.2.4 Hypertext Transfer Protocol (HTTP) Streaming................................6 A.3 Real-time services specific Protocols........................................................7 A.3.1 Real Time Transport Protocol (RTP) and Real Time Control Protocol (RTCP)..........................................................................................7 A.3.2 Real Time Streaming Protocol (RTSP)..............................................7 A.3.3 Reservation Protocol (RSVP).............................................................8 A.3.4 Session Description Protocol (SDP)..................................................8 A.3.5 Session Initiation Protocol (SIP)........................................................9 A.4 Audio and Video Standards....................................................................10 A.4.1 H.323................................................................................................10 A.4.2 MPEG...............................................................................................12 A.4.3 T.120.................................................................................................14 A.4.4 Other standards................................................................................16 A.5 Proprietary Encoding Schemes...............................................................17 A.5.1 RealNetwork’s RealSystem G2.........................................................17 A.5.2 Microsoft NetShow and Active Streaming Format...........................18 A.5.3 Apple QuickTime..............................................................................18 A.6 Coding Techniques Description..............................................................18 A.6.1 Layered Coding.................................................................................18 A.6.2 Redundant Coding............................................................................19 A.6.3 Transcoding......................................................................................19 ANNEX B: REVIEW ON TOOLS & COMMERCIAL PRODUCTS.......20 B.1 Applications audio/video streaming .......................................................20 B.1.1 RealAudio/Real Video.......................................................................20 B.1.2 Microsoft NetShow Services.............................................................22 page iv (viii) © 1999 EURESCOM Participants in Project P913-GI
  7. 7. Deliverable 1 Volume 2: Annexes B.1.3 Xing Tech. Streamworks...................................................................23 B.1.4 VDO Live..........................................................................................24 B.1.5 Apple Quicktime................................................................................25 B.1.6 Cisco IP/TV.......................................................................................26 B.1.7 DT/MTG Music on Demand application..........................................27 B.1.8 Oracle iTV........................................................................................28 B.1.9 Feature “at-a-glance“ comparison form.........................................31 B.2 Applications for telephony/conferencing................................................32 B.2.1 Microsoft NetMeeting.......................................................................32 B.2.2 CU-SeeMe.........................................................................................33 B.2.3 WhitePine’s MeetingPoint tools ......................................................33 B.2.4 VocalTec Internet Phone Lite...........................................................34 B.2.5 VDO Phone.......................................................................................34 B.2.6 Isabel ................................................................................................36 B.2.7 NetSpeak WebPhone.........................................................................37 B.2.8 Netscape CoolTalk............................................................................37 B.2.9 VIC/VAT - Video Conferencing Tool................................................38 B.2.10 Intel Internet Video Phone..............................................................39 B.2.11 Hardware based Internet conferencing solutions...........................39 B.2.12 Feature “at-a-glance“ comparison form.......................................43 ANNEX C: MARKET TRENDS...................................................................45 C.1 Introduction.............................................................................................45 C.2 Market Trends in different Business Segments.......................................45 C.2.1 Internet “Core Technology”............................................................45 C.2.2 Trends in Software Technology...........................................................47 C.2.3 Internet Content oriented Applications............................................50 C.2.4 Offers from Network Operators........................................................51 C.2.5 Internet Service Providers................................................................52 C.3 Market Trends in different Global Regions............................................53 C.3.1 North America..................................................................................53 C.3.2 Europe..............................................................................................54 C.3.3 Asian Pacific region.........................................................................54 C.4 Trends in the Behaviour of Users............................................................54 C.4.1 Private Users....................................................................................54 C.4.2 Public Users......................................................................................55 C.4.3 Corporate Users...............................................................................55 C.5 Market Trends on Quality-Requirements................................................56 C.6 Figures about the market development...................................................57 C.7 Conclusions about Market Trends...........................................................58 PREFACE...........................................................................................................I LIST OF AUTHORS......................................................................................III TABLE OF CONTENTS................................................................................IV © 1999 EURESCOM Participants in Project P913-GI page v (viii)
  8. 8. Volume 2: Annexes Deliverable 1 ABBREVIATIONS......................................................................................VIII ANNEX A: REVIEW OF INTERNET STANDARDS..................................1 A.1 Standardisation Bodies..............................................................................1 A.1.1 International Telecommunications Union (ITU)................................1 A.1.2 The Internet Engineering Task Force (IETF)....................................1 A.1.3 European Telecommunications Standards Institute (ETSI)...............1 A.1.4 International Multimedia Teleconferencing Consortium (IMTC)......1 A.1.5 International Standardisation Organisation (ISO) & ISO/MPEG.....1 A.1.6 DAVIC.................................................................................................2 A.2 The Internet Suite of Protocols.................................................................2 A.2.1 Internet Protocol (IP) ........................................................................2 A.2.2 Transmission Control Protocol (TCP)...............................................5 A.2.3 User Datagram Protocol (UDP)........................................................6 A.2.4 Hypertext Transfer Protocol (HTTP) Streaming................................6 A.3 Real-time services specific Protocols........................................................7 A.3.1 Real Time Transport Protocol (RTP) and Real Time Control Protocol (RTCP)..........................................................................................7 A.3.2 Real Time Streaming Protocol (RTSP)..............................................7 A.3.3 Reservation Protocol (RSVP).............................................................8 A.3.4 Session Description Protocol (SDP)..................................................8 A.3.5 Session Initiation Protocol (SIP)........................................................9 A.4 Audio and Video Standards....................................................................10 A.4.1 H.323................................................................................................10 A.4.2 MPEG...............................................................................................12 A.4.3 T.120.................................................................................................14 A.4.4 Other standards................................................................................16 A.5 Proprietary Encoding Schemes...............................................................17 A.5.1 RealNetwork’s RealSystem G2.........................................................17 A.5.2 Microsoft NetShow and Active Streaming Format...........................18 A.5.3 Apple QuickTime..............................................................................18 A.6 Coding Techniques Description..............................................................18 A.6.1 Layered Coding.................................................................................18 A.6.2 Redundant Coding............................................................................19 A.6.3 Transcoding......................................................................................19 ANNEX B: REVIEW ON TOOLS & COMMERCIAL PRODUCTS.......20 B.1 Applications audio/video streaming .......................................................20 B.1.1 RealAudio/Real Video.......................................................................20 B.1.2 Microsoft NetShow Services.............................................................22 B.1.3 Xing Tech. Streamworks...................................................................23 B.1.4 VDO Live..........................................................................................24 B.1.5 Apple Quicktime................................................................................25 B.1.6 Cisco IP/TV.......................................................................................26 B.1.7 DT/MTG Music on Demand application..........................................27 B.1.8 Oracle iTV........................................................................................28 B.1.9 Feature “at-a-glance“ comparison form.........................................31 B.2 Applications for telephony/conferencing................................................32 B.2.1 Microsoft NetMeeting.......................................................................32 page vi (viii) © 1999 EURESCOM Participants in Project P913-GI
  9. 9. Deliverable 1 Volume 2: Annexes B.2.2 CU-SeeMe.........................................................................................33 B.2.3 WhitePine’s MeetingPoint tools ......................................................33 B.2.4 VocalTec Internet Phone Lite...........................................................34 B.2.5 VDO Phone.......................................................................................34 B.2.6 Isabel ................................................................................................36 B.2.7 NetSpeak WebPhone.........................................................................37 B.2.8 Netscape CoolTalk............................................................................37 B.2.9 VIC/VAT - Video Conferencing Tool................................................38 B.2.10 Intel Internet Video Phone..............................................................39 B.2.11 Hardware based Internet conferencing solutions...........................39 B.2.12 Feature “at-a-glance“ comparison form.......................................43 ANNEX C: MARKET TRENDS...................................................................45 C.1 Introduction.............................................................................................45 C.2 Market Trends in different Business Segments.......................................45 C.2.1 Internet “Core Technology”............................................................45 C.2.2 Trends in Software Technology...........................................................47 C.2.3 Internet Content oriented Applications............................................50 C.2.4 Offers from Network Operators........................................................51 C.2.5 Internet Service Providers................................................................52 C.3 Market Trends in different Global Regions............................................53 C.3.1 North America..................................................................................53 C.3.2 Europe..............................................................................................54 C.3.3 Asian Pacific region.........................................................................54 C.4 Trends in the Behaviour of Users............................................................54 C.4.1 Private Users....................................................................................54 C.4.2 Public Users......................................................................................55 C.4.3 Corporate Users...............................................................................55 C.5 Market Trends on Quality-Requirements................................................56 C.6 Figures about the market development...................................................57 C.7 Conclusions about Market Trends...........................................................58 © 1999 EURESCOM Participants in Project P913-GI page vii (viii)
  10. 10. Volume 2: Annexes Deliverable 1 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 Differenciated 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 Fiber 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 Markup Language HTTP HyperText Transfer Protocol IAB Internet Architecture Board IAP Internet Access Provider ICMP Internet Control Messaging Protocol IGMP Internet Group Management Protocol page viii (viii) © 1999 EURESCOM Participants in Project P913-GI
  11. 11. Deliverable 1 Volume 2: Annexes 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 Tunneling 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 Center NNTP Network News Transfer Protocol NoD News-on-Demand OSI Open Systems Interconnect OSPF Open Shortest Path First PC Personal Computer PHB Per Hop Behavior PIN Personal Identification Number PPP Point-to-Point Protocol PPTP Point-to-Point Tunneling Protocol PQ Priority Queuing PSK Phase-Shift-Keying © 1999 EURESCOM Participants in Project P913-GI page ix (viii)
  12. 12. Volume 2: Annexes Deliverable 1 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 Synchronized 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 page x (viii) © 1999 EURESCOM Participants in Project P913-GI
  13. 13. Deliverable 1 Volume 2: Annexes Annex A: Review of Internet Standards A number of standards have been developed for the Internet by a number of international standardisation bodies and independent organisations. This section identifies and discusses the most important standardisation bodies which exist and the main standards which are in use. A.1 Standardisation Bodies A.1.1 International Telecommunications Union (ITU) A.1.2 The Internet Engineering Task Force (IETF) The IETF defines the standards for use on the Internet. It is strongly supported by industrial and academic institutions. The IETF, as with the ITU, operates by forming working groups which research and standardise various aspects of Internet technology. In general, the IETF is less bureaucratic that the ITU-T and is more fast- moving in its deliberations. A.1.3 European Telecommunications Standards Institute (ETSI) ETSI is responsible for developing European standards for telecommunications and does this in close co-operation with other bodies such as the ITU-T, as well as with industrial and academic institutions. ETSI is currently operating the TIPHON project, a world-wide project which is concerned with the interoperability of services between IP networks and non-IP networks (e.g. PSTN, ISDN, GSM and UMTS). A.1.4 International Multimedia Teleconferencing Consortium (IMTC) The IMTC aims to promote the development and implementation of interoperable multimedia solutions based on international standards, and has over 140 members and affiliates from across the globe. The IMTC organises interoperability test sessions which are attended by vendors of standards-based conferencing products and services. The IMTC also tries to educate businesses and residential customers about the potential value and benefits to be gleaned from the technologies and resultant applications. IMTC members provide submissions and feedback to the standardisation bodies in an attempt to help improve the interoperability and usability of multimedia teleconferencing products. A.1.5 International Standardisation Organisation (ISO) & ISO/MPEG The ISO was founded in 1947 with the aim of promoting the development of standards to enable global exchanging of goods and services and to encourage co- operation in the areas of intellectual, scientific and commercial activity. In terms of the Internet, the ISO and the IETF communicate with each other to aid the development of internationally acceptable standards. The Moving Picture Coding Experts Group (MPEG) was established in January 1988 with the mandate to develop international standards for compression, decompression, processing, and coded representation of moving pictures, audio and their combination. It operates in the framework of the Joint ISO/IEC Technical Committee (JTC 1) on Information Technology and is formally WG11 of SC29. MPEG usually holds three © 1999 EURESCOM Participants in Project P913-GI page 1 (60)
  14. 14. Volume 2: Annexes Deliverable 1 meetings a year, attended by some 300 experts from 20 countries. So far the MPEG family of standards includes MPEG-1, MPEG-2 and MPEG-4, formally known as ISO/IEC-11172, ISO/IEC-13818 and ISO/IEC-14496. A.1.6 DAVIC DAVIC was formed in 1994 in Switzerland and has a membership which includes over 157 companies from a diverse range of countries. This membership includes companies from many different sections of the audio/visual industry. The main aims of DAVIC are to promote the success of interactive digital audio/visual applications and services and to develop industry standards for end-to-end interoperability of broadcast and interactive digital audio/visual and multimedia communication. To date DAVIC specifications 1.0 to 1.4 have been published. DAVIC is working to extend the standards for TV-anytime and TV-anywhere into IP-based applications and services. A.2 The Internet Suite of Protocols Many different protocols are used over the Internet. Each of the protocols have their own characteristics, strengths and weaknesses and are used for different types of applications which require different Quality′s of Service (QoS). The entire set of Internet Protocols is referred to as the IP Suite of Protocols. This section briefly examines each of the protocols, and the standards by which they are defined. A.2.1 Internet Protocol (IP) Internet Protocol (IP) was originally developed by the US Defence Advanced Research Projects Agency (DARPA) in a strategic attempt to create a computer network that was distributed over a very wide area to reduce the potential risk of information loss in the event of a nuclear strike on a US city. It evolved from the use of multiple interconnected X.25 WANs and X.75-based gateways which were unsuitable for internet-wide deployment due to X.25 packets having a very large header, resulting in a low packet throughput in the networks. The number of IP networks in use has grown considerably, and these networks are interconnected to form the global Internet. IP is an internet-wide protocol which enables two transport protocol entities resident on different hosts to exchange message units in a transparent way. IP is only one of the many protocols in the complete protocol suite. There are several versions of IP in commercial use. The version which is in general use at the moment is IPv4. However a new version, IPv6 is currently in use in a number of research institutions, and is likely to be used more widely in the early years of the next millennium. This section discusses the properties of both versions, and highlights the similarities and differences between them. A.2.1.1 IPv4 As with all packet-based protocols, IPv4 datagrams are packets of data which contain some header information and the data payload. Figure 1 shows the format of IPv4 datagrams. page 2 (60) © 1999 EURESCOM Participants in Project P913-GI
  15. 15. Deliverable 1 Volume 2: Annexes Version IHL Type of Service Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options Padding Datagram payload <65'536 bytes Figure 1: IP Packet structure (IPv4) Below is a list and description of the field types in the IP datagram : • Version: This field indicates what version of IP was used to create the datagram. • Header length: This indicates the actual length of the datagram in multiples of 32- bit words. • Type of Service: This field allows an application to specify the preferred attributes of the route which the packet will take. Each gateway and router uses this information to forward the packet across the most suitable link. • Total Length: This indicates the total length of the datagram including the header and payload • Identification: Allows one user message to be sent in a number of different datagrams. • Flag bits: Three bits which are used to indicate various requirements to the IP gateways and routers. • Time to Live: specifies a maximum number of hops for which a datagram can be in transit across the Internet. If the field has a zero value, the packet is discarded. • Protocol: Allows the destination IP to pass the datagram to the relevant protocol. • Header Checksum: Helps to avoid corruption of the header by performing 1’s compliment on the header and then inverting this at the receiver • Destination/Source address: IP addresses of the source and destination hosts. • Options: This field carries additional information regarding security, source routing, route recording, stream identification and time-stamping. IPv4 is based upon open standards which were developed by a number of educational and research institution, including DARPA itself. These standards were initially published in 1981 and have been modified only slightly since then. The main IPv4 © 1999 EURESCOM Participants in Project P913-GI page 3 (60)
  16. 16. Volume 2: Annexes Deliverable 1 standard is RFC 7911. A new version of IP, IPv6, has been developed to help overcome the restrictions of IPv4. A.2.1.2 IPv6 While IPv4 has been the main protocol which has been used on the Internet over the last twenty years or so, it has a number of weaknesses in terms of scalability, security, management and performance. The addressing fields of the IPv4 packet header can only accommodate 32-bit addresses, meaning that there will be an insufficient number of IP addresses to cope with the continuing popularity and increasing ubiquity of the Internet. An additional problem with IPv4 was that the packet-routing tables which are required to be stored at each exterior gateway were becoming very large due to the almost random way in which IP addresses were allocated. IPv6 was developed in order to alleviate these problems. IPv6 provides enhanced support for multicasting and is capable of supporting ‘anycast’ applications whereby a packet is forwarded on to any one person from a group of people. It also enables users to transmit packets more securely and to authenticate the source of an incoming packet. By introducing a simple hierarchical addressing structure, and by simplifying the standard header of packets, network performance should improve. In addition, IPv6 has a means of specifying a QoS at the network level, meaning that different traffic types can be handled more appropriately. The header of IPv6 packets is shown in Figure 2. 32 bits Version Flow Label Next Header Time-to-live Basic Header Payload Length Source Address Destination Address Possible Extension Headers Payload Figure 2: Structure of IPv6 Packet The header of IPv6 packets has been simplified relative to IPv4 to enable faster processing of packets and higher throughput at routers. The extension headers are only included in the packet if the packet requires any special services or processing at each router. In general, the fields in the IPv6 header perform similar functions to those in the IPv4 header. There are, however, some new fields in the IPv6 header. The flow label identifies the type of information being carried by the packet. The maximum size of the payload is 65536 octets as before, although larger payload sizes can be accommodated in IPv6 by setting the Payload Length field to zero and using an optional header to specify the actual size of the payload. The time-to-live field 1 This document (RFC791) can be viewed at http://www.ietf.org/rfc/rfc0791.txt page 4 (60) © 1999 EURESCOM Participants in Project P913-GI
  17. 17. Deliverable 1 Volume 2: Annexes contains a number which indicates the maximum number of links over which a packet is allowed to pass before it is discarded. This prevents it from circulating endlessly on the networks. The source and destination address fields both contain 128-bit hierarchical addresses. This address space is sufficient to allow everyone on the planet to have numerous IP addresses. While IPv4-based exterior gateways use netid and subnetid addresses, IPv6-based exterior gateways use an additional address called the cluster address. This address identifies the topological region in which the network (and hence the host) is located. The complete standard for IPv6 defined in IETF document RFC18831. A.2.2 Transmission Control Protocol (TCP) Since the maximum payload size of an IP datagram is 65536 octets, it is often necessary to break up larger user messages into many packets and send them individually across the network. When the packets are received at the destination, the original message is re-assembled. This process is achieved by using Transmission Control Protocol (TCP). TCP is responsible for establishing the end to end connection and allocating input and output ports to be used for the duration of the communication. TCP breaks up the message into fixed-size packets and adds the TCP header, which is shown in Figure 3 below. These TCP packets are then passed to the IP which places them inside the IP datagrams and adds the IP header. 32 bits Source Port Destination Port Sequence Number Acknowledgement Number Header Window Size URG ACK PSH SYN RST FIN length Unused Checksum Urgent pointer Options (0 or more 32-bit words) Data Payload Figure 3: TCP Header structure The source and destination ports contain information regarding which TCP ports are to be used by the communicating devices. The sequence number ensures that the receiving terminal can assemble the incoming packets into the correct order, and the acknowledgement number indicates what acknowledgement packet number should be sent from the receiver. The total number of octets in the packet is counted and the result is placed into the Checksum field. This helps the routing equipment and the receiver check for errors or corrupted packets. Once the TCP packet is assembled, it is passed to the IP. The IP is not concerned with what is in the TCP payload, or the TCP header. IP's function is to find a route for the packet across the network. TCP is responsible for arranging retransmission of packets 1 This document can be viewed at http://www.ietf.org/rfc/rfc1183.txt © 1999 EURESCOM Participants in Project P913-GI page 5 (60)
  18. 18. Volume 2: Annexes Deliverable 1 in the event of packet loss or corruption. This ability to deal with lost and corrupted packets means that TCP can provide a reliable stream of data. The TCP standard is defined in IETF document RFC7931. A.2.3 User Datagram Protocol (UDP) Unlike TCP, the User Datagram Protocol (UDP) does not require that a connection be established with another program in order to exchange information. Data is exchanged in discrete units called datagrams, which are similar to IP datagrams. In fact, the only features that UDP offers over raw IP datagrams are the inclusion of port numbers and an optional checksum. In UDP, there is no scope for retransmitting packets which have been lost or corrupted. As such, UDP is sometimes referred to as an ‘unreliable’ protocol because when a program sends a UDP datagram over the network, there is no method of confirming its arrival at the destination. This means that the sender and receiver must typically implement their own application-layer protocol to deal with packet loss and data corruption. Much of the work that TCP does transparently (such as generating checksums, acknowledging the receipt of packets, arranging retransmission of lost packets and so on) must be performed by the application itself. With the limitations of UDP, one might wonder why it is used at all. UDP has an advantage over TCP in two critical areas: speed and packet overhead. Because TCP is a reliable protocol, it goes to great lengths to insure that data arrives at its destination intact, and as a result it exchanges a fairly high number of packets over the network. UDP doesn't have this overhead, and is considerably faster than TCP. In those situations where speed is paramount, or the number of packets sent over the network must be kept to a minimum, UDP can be a solution. The UDP standard is defined in IETF document RFC7682. A.2.4 Hypertext Transfer Protocol (HTTP) Streaming Hypertext Transfer Protocol (HTTP) is the protocol which is used by most servers for communications with remote hosts and enables the remote host to gain access to the files and drives on another host (the server) which could be in another network on another continent. For the remote host to be able to get access to the required file on the other machine, the other machine must be running a web server program. The remote host sends a request to the server, which then retrieves the file from the appropriate location and returns it to the host via the relevant protocol (e.g. TCP/IP). The server also indicates to the host what type of file is being returned, so that the host can launch the necessary application(s). HTTP only specifies what the host and the server say to each other, and not what means they use to say it. The TCP/IP protocol suite is used for this. The standard for HTTP 1.0 is defined in IETF document RFC1945 3 and the standard for HTTP 1.1 is defined in IETF document RFC20684. 1 This document can be viewed at http://www.ietf.org/rfc/rfc0793.txt 2 This document can be viewed at http://www.ietf.org/rfc/rfc0768.txt 3 This document can be viewed at http://www.ietf.org/rfc/rfc1945.txt 4 This document can be viewed at http://www.ietf.org/rfc/rfc2068.txt page 6 (60) © 1999 EURESCOM Participants in Project P913-GI
  19. 19. Deliverable 1 Volume 2: Annexes A.3 Real-time services specific Protocols In the purpose of real-time services such as audio-video streaming or video- conferencing, many new protocols have been standardised in the last few years. These protocols have the goal of compensating for the lack of features proposed by the classic Internet suite of protocols in regards with real-time services specificity. A.3.1 Real Time Transport Protocol (RTP) and Real Time Control Protocol (RTCP) Real Time Transport Protocol (RTP) is an IP-based protocol which enables real-time streams such as video and audio to be transported across the Internet. RTP provides services for the transported media such as time-reconstruction, loss detection, security and content identification. It was designed mainly for use with multicast, but can also be used with unicast. RTP provides a solution to the problem of trying to carry synchronous multimedia traffic over an asynchronous shared datagram network. It provides time-stamping of packets to enable the receiver to play back the media at the correct rate. The time stamping also enables the application layer to synchronise different streams, such as audio and video data in MPEG. The packets also require to be put in order, as one video frame may be split into a number of packets. Sequence numbers are added to the packet overhead for this purpose. In a multimedia session, each medium is carried in a separate RTP session and synchronisation of the two media sessions must be performed by the application. RTP works in unison with the Real Time Control Protocol (RTCP) to get feedback on the QoS as well as information regarding who is participating in the on-going session. RTCP also provides information on source identification, inter-media synchronisation and control information scaling. Both RTP and RTCP are usually transmitted over UDP, although efforts have been made to allow them to be transmitted over the Connectionless Network Protocol (CLNP), Internetwork Packet Exchange (IPX) and ATM networks. Some extensions to RTP and RTCP headers for specific audio-video codecs are defined in specific internet-drafts or RFCs The standards for RTP and RTCP are defined in IETF document RFC18891. A.3.2 Real Time Streaming Protocol (RTSP) 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. The Real-Time Streaming Protocol (RTSP) establishes and controls either a single or several time-synchronised streams of continuous media such as audio and video. It does not typically deliver the continuous streams itself, although interleaving of the continuous media stream with the control stream is possible. In other words, RTSP acts as a "network remote control" for multimedia servers. There is no notion of an RTSP connection; instead, a server maintains a session labelled by an identifier. An RTSP session is in no way tied to a transport-level connection such as a TCP connection. The streams controlled by RTSP may use RTP, but the operation of RTSP does not depend on the transport mechanism used to carry 1 This document can be viewed at http://www.ietf.org/rfc/rfc1889.txt © 1999 EURESCOM Participants in Project P913-GI page 7 (60)
  20. 20. Volume 2: Annexes Deliverable 1 continuous media. The protocol is intentionally similar in syntax and operation to HTTP/1. Therefore it has some overlap in functionality with HTTP. It also may interact with HTTP in that the initial contact with streaming content is often to be made through a web page. However, RTSP differs fundamentally from HTTP in that data delivery takes place out-of-band in a different protocol. The protocol supports the following operations: retrieval of media from media server, invitation of a media server to a conference, addition of media to an existing presentation. The "rtsp" schemes are used to refer to network resources via the RTSP protocol. The scheme-specific syntax and semantics for RTSP URLs are as follows : rtsp_URL = rtsp://host:port[abs_path] For example, the RTSP URL rtsp://media.example.com:554/twister/audiotrack, identifies the audio stream within the presentation "twister", which can be controlled via RTSP requests issued over a TCP connection to port 1554 of host media.example.com. The standard for RTSP is defined in the IETF document RFC23261. A.3.3 Reservation Protocol (RSVP) The Reservation Protocol (RSVP) is a control and signalling protocol which allows the data receiver to request an end-to-end QoS for its data flows. The real time application uses RSVP to reserve space in the buffers of nodes along the transmission path so that the necessary bandwidth can be available when the transmission actually takes place. The RSVP negotiates the connection parameters and maintains router and host states so that the requested service can be provided. Each router may deal with RSVP requests in different ways and may use different means of reserving bandwidth on the channel. The reservation process does not actually provide the guaranteed QoS for the application, but it does guarantee that the network resources required will be available when transmission actually takes place. The processing capability and task scheduling of the computer they are using can also affect the QoS perceived by the end users. RSVP does not scale well, and as a result much research activity has gone into finding other ways of improving QoS. The most notable outcomes of this research so far include Integrated and Differential Services. These technologies are discussed in Section 2.5.2. The standards for RSVP are defined in the IETF documents RFC22052, RFC22063, RFC22074, RFC22085, RFC22096. A.3.4 Session Description Protocol (SDP) The Session Description Protocol, SDP, is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. It has been standardised by the Multiparty Multimedia Session Control (MMUSIC) working group of the IETF. 1 This document can be viewed at http://www.ietf.org/rfc/rfc2326.txt 2 This document can be viewed at http://www.ietf.org/rfc/rfc2205.txt 3 This document can be viewed at http://www.ietf.org/rfc/rfc2206.txt 4 This document can be viewed at http://www.ietf.org/rfc/rfc2207.txt 5 This document can be viewed at http://www.ietf.org/rfc/rfc2208.txt 6 This document can be viewed at http://www.ietf.org/rfc/rfc2209.txt page 8 (60) © 1999 EURESCOM Participants in Project P913-GI
  21. 21. Deliverable 1 Volume 2: Annexes This protocol has the purpose of advertising multimedia conferences and communicate the conference addresses and conference tool-specific information necessary for participation, on the Internet multicast backbone (Mbone.) The Mbone is the part of the internet that supports IP multicast, and thus permits efficient many-to-many communication. It is used extensively for multimedia conferencing. Such conferences usually have the property that tight co-ordination of conference membership is not necessary; to receive a conference, a user at an Mbone site only has to know the conference's multicast group address and the UDP ports for the conference data streams. Session directories assist the advertisement of conference sessions and communicate the relevant conference set-up information to prospective participants. SDP is designed to convey such information to recipients. SDP is purely a format for session description – it does not incorporate a transport protocol, and is intended to use different transport protocols as appropriate including the Session Announcement Protocol, Session Initiation Protocol, Real-Time Streaming Protocol, electronic mail using the MIME extensions, and the Hypertext Transport Protocol. SDP is not intended for negotiation of media encodings. The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. A multimedia session, for these purposes, is defined as a set of media streams that exist for some duration of time. Media streams can be many-to-many. The times during which the session is active need not be continuous. In such an environment, SDP serves two primary purposes. It is a means to communicate the existence of a session, and is a means to convey sufficient information to enable joining and participating in the session. In a unicast environment, only the latter purpose is likely to be relevant. The standards for SDP is defined in IETF document RFC23271. A.3.5 Session Initiation Protocol (SIP) The Session Initiation Protocol can be used to initiate sessions as well as invite members to sessions that have been advertised and established by other means. Sessions can be advertised using multicast protocols such as SAP, electronic mail, news groups, web pages or directories (LDAP), among others. SIP supports five facets of establishing and terminating multimedia communications: • User location: determination of the end system to be used for communication; • User capabilities: determination of the media and media parameters to be used; • User availability: determination of the willingness of the called party to engage in communications; • Call setup: "ringing", establishment of call parameters at both called and calling party; • Call handling: including transfer and termination of calls. SIP can also initiate multi-party calls using a multipoint control unit (MCU) or fully- meshed interconnection instead of multicast. Internet telephony gateways that connect Public Switched Telephone Network (PSTN) parties can also use SIP to set up calls between them. 1 This document can be viewed at http://www.ietf.org/rfc/rfc2327.txt © 1999 EURESCOM Participants in Project P913-GI page 9 (60)
  22. 22. Volume 2: Annexes Deliverable 1 SIP can also be used in conjunction with other call setup and signaling protocols. In that mode, an end system uses SIP exchanges to determine the appropriate end system address and protocol from a given address that is protocol-independent. For example, SIP could be used to determine that the party can be reached via H.323, obtain the H.245 gateway and user address and then use H.225.0 to establish the call. In another example, SIP might be used to determine that the callee is reachable via the PSTN and indicate the phone number to be called, possibly suggesting an Internet-to- PSTN gateway to be used. SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed, but SIP can be used to introduce conference control protocols. SIP does not allocate multicast addresses. SIP can invite users to sessions with and without resource reservation. SIP does not reserve resources, but can convey to the invited system the information necessary to do this. The standard for SIP is defined in IETF document RFC25431. A.4 Audio and Video Standards Real time applications such as video and audio must use some sort of compression/encoding scheme to keep the required bandwidth to a minimum without significantly reducing the perceived quality of the media. This section discusses some of the main internationally standardised encoding schemes used for real-time communications on the Internet. A.4.1 H.323 The H.3232 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 conflicts. H.323 is an umbrella recommendation from the ITU that sets standards for multimedia communications over networks that do not provide a guaranteed QoS. Thus, H.323 standards are important building blocks for a new range of collaborative applications for multimedia communications. The H.323 specification was approved by ITU Study Group 16 in 1996, and version 2 was approved in January 1998. The standard has a very broad scope, dealing with issues relevant to stand-alone devices, embedded PC technology and point-to-point and multipoint conferencing. H.323 also deals with call control, multimedia management, bandwidth management and interfacing between LANs and other networks. H.323 is a subset of the H.32X series of standards which enable videoconferencing across a range of networks. H.323 is a comprehensive yet flexible standard which can be applied to voice-only handsets as well as full multimedia videoconferencing applications. H.323 establishes standards for compression and decompression of audio and video data streams, ensuring equipment and software from different vendors will have some common support. The standard also enables the communicating parties to exchange information regarding their processing capabilities. H.323 is designed to run on top of 1 This document can be viewed at http://www.ietf.org/rfc/rfc2543.txt 2 This document can be viewed at http://www.itu.int. A license is required to gain access to ITU documents. page 10 (60) © 1999 EURESCOM Participants in Project P913-GI
  23. 23. Deliverable 1 Volume 2: Annexes common network architectures. Thus H.323 applications will be able to evolve to take advantage of enhanced network capabilities. The standard provides bandwidth management to prevent the network from being saturated with multimedia traffic. The network manager can limit the total number of simultaneous H.323 connections and can also limit the amount of bandwidth available to H.323 applications. Multipoint conferences can take advantage of H.323‘s multicast capability to make more efficient use of the bandwidth available. H.323 has a means of linking LAN-based desktop systems with ISDN-based group systems to enable conferencing from LANs to remote sites. H.323 uses common codec technology from various videoconferencing standards to minimise transcoding delays to provide optimum performance. The H.323 standard is based on the IETF real-time protocol (RTP) and real-time control protocol (RTCP), with additional protocols for call signalling and data and audio-visual communications. H.323 provides a variety of options for audio and video coding. Two codecs, G.711 for audio and H.261 for video, are required by the H.323 specification. H.323 terminals must be able to send and receive G.711 encoded audio (ITU-T A-law and µ- law – as used in standard PCM telephony). There is additional support for audio and video codecs provided in the standard. This gives a variety of standard bit rate, delay, and quality options which are suitable for a range of different networks and applications. H.323 also enables products to negotiate non-standard audio and video codecs. The list below1 describes the audio and video codecs (G.711 and H.261) which are required for H.323, as well as other codecs which can be included. G.723 and H.263 offer the low-bit rate connections necessary for audio and video transmission over the Internet. : • G.711. The G.711 codec can transmit audio at 48, 56 or 64 kb/s. This codec is appropriate for audio over higher speed connections. • G.723. The G.723 audio codec specifies the format and algorithm used to send and receive voice communications over the network. G.723 transmits audio at 5.3 and 6.3 kb/s, which is adequate for Internet telephony over low-bit-rate connections. • H.261. The H.261 codec transmits video images at 64 kb/s. This codec is appropriate for video over higher speed connections. • H.263. The H.263 video codec specifies the format and algorithm used to send and receive video images over the network. This codec supports CIF, QCIF, and SQCIF picture formats and is adequate for Internet transmission over low-bit-rate connections, such as a 28.8 kb/s modem. The architecture of H.323 is shown in Figure 4. 1 The complete standards of G.711, G.723, H.261 and H.263 can be viewed at http://www.itu.net. A licence is required to gain access to these documents. © 1999 EURESCOM Participants in Project P913-GI page 11 (60)
  24. 24. Volume 2: Annexes Deliverable 1 Audio Codec Microphone/ G.711 Speaker G.723 G.729 RTP Camera/ Video Codec Display H.261 H.263 Data Data LAN Equipment Interface Interface T.120 System Control System H.245 Control Control Q.931 User Call Setup Interface RAS Interface Figure 4: Architecture of H.323 H.263 is an ITU standard for video-conferencing communication and is optimised for relatively low data rates and low-motion video. The standard is an advancement on the H.261 and M-PEG video standards. It was designed to produce better picture qualities at data rates below 64 kb/s. H.263 is supported by many architectures including Apple’s QuickTime, Microsoft NetShow and Video for Windows. H263 offers relatively good quality at low data rates, and offers better performance than H.261 in general. However, H.263 requires very powerful processors, and low-to- medium specification processors may have trouble dealing with bit-rates in excess of 50 kb/s. The standard is most suited to encoding low-motion video. A.4.2 MPEG MPEG (Motion Pictures Expert Group) is an ISO study group which has developed a series of standards for the compression and transmission of digital video and audio streams and files. The standards define a compressed bit stream, which implies the use of a decompresser. The actual compression algorithm implemented is dependent on the vendor. The underlying philosophy of the MPEG standards is to capitalise on the nature of the human visual and audio system to reduce the amount of information required to digitally represent a moving picture or sound wave. A.4.2.1 MPEG-video Like it’s sister standard JPEG, MPEG-video utilises the discrete cosine transform (DCT) and zig-zag coding to discard the high spatial frequencies which are not essential requirements of the human visual system. The visual information which remains after the DCT has been performed is quantised and encoded to remove any statistical redundancy in the bit stream. For compression of video streams and files, MPEG uses adjacent frames of the sequence, due to the fact that there is typically a very high correspondence between adjacent frames, and it would be wasteful to encode each frame independently when adjacent frames have such similarity. Figure 5 shows how adjacent frames are used to encode the present frame for MPEG-1. page 12 (60) © 1999 EURESCOM Participants in Project P913-GI
  25. 25. Deliverable 1 Volume 2: Annexes I B1 B2 P1 B3 B4 P2 Figure 5: MPEG Inter-frame relations • I-frame (Intra-frame): Encoded separately (using DCT) and add error resilience at the expense of a large data rate. • P-frame (Inter-frame): Uses DCT encoding with motion compensation from preceding frames. • B-frame (Inter-frame): Uses DCT encoding with both forward and backward motion compensation. While the use of adjacent frames in the sequence can help to significantly reduce the amount of data required to represent the video, this advantage is partially offset by the delay introduced by requiring a number of adjacent frames to be cached to enable decoding to take place. A.4.2.2 MPEG-audio MPEG-audio principle is based on the human perception ear. The MPEG Audio coders, aimed for generic audio, i.e. all types of speech and music signals, are perceptual audio coders, rather than so-called 'waveform coders' : its goal is to ensure that the output signal sounds the same to a human listener. It uses a psychoacoustic effect called the 'auditory masking', where parts of a signal are not audible due to the function of the human auditory system. In order to remove the irrelevant part of a signal, the encoder contains a psychoacoustic model, which analyses the input signals within consecutive time blocks and determines for each block the spectral components of the input audio signal by applying a frequency transform. Then it estimates the just noticeable noise- level. In parallel, the input signal is fed through a time-to-frequency mapping, resulting in spectrum components for subsequent coding. In its quantisation and coding stage, the encoder tries to allocate the available number of data bits in a way that meets both the bitrate and masking requirements. There are 3 layers in MPEG-Audio standard, considering the complexity of the encoder and decoder, the encoder/decoder delay, and the coding efficiency • Layer I has the lowest complexity and is specifically suitable for applications where also the encoder complexity plays an important role. HiFi quality is reached with 384 Kbit/s in stereo mode. • Layer II requires a more complex encoder and a slightly more complex. Compared to Layer I, Layer II is able to remove more of the signal redundancy and to apply the psychoacoustic threshold more efficiently. HiFi quality is reached with 256 Kbit/s in stereo mode. © 1999 EURESCOM Participants in Project P913-GI page 13 (60)
  26. 26. Volume 2: Annexes Deliverable 1 • Layer III is again more complex and is directed towards lower bit rate applications due to the additional redundancy and irrelevancy extraction from enhanced frequency resolution in its filterbank. HiFi quality is reached with 128 Kbit/s in stereo mode. A.4.2.3 MPEG-system MPEG-Systems is a standard that defines the syntax and semantics of bitstreams in which digital audio and visual data are multiplexed. Such bitstreams are said to be MPEG Systems compliant. This specification does not mandate, however, how equipment that produces, transmits, or decodes such bitstreams should be designed. As a result, the specification can be used in a diverse array of environments, including local storage, broadcast (terrestrial and satellite), as well as interactive environments. A.4.2.4 MPEG levels There are three levels of MPEG compression, MPEG-1, MPEG-2 and MPEG-4. A fourth standard, MPEG-7 ("Multimedia Content Description Interface") is being developed at the time of writing, and has the purpose to extend the limited capabilities of proprietary solutions in identifying content on multimedia databases. MPEG-11 is for use over connections with a data capacity of up to 1.5 Mbit/s. It can compress a 352x240x30Hz video to around 1.25 Mbit/s, and stereo audio to around 240 kbit/s. It uses non-interlaced video, and has been optimised for CD-ROM applications. MPEG-22 is for use over higher bandwidth connections for broadcast applications like digital television (up to 15 Mbit/s for standard TV, 60 Mbit/s for HDTV). It can deal with a variety of frame sizes and up to 5 audio channels simultaneously (enabling HDTV and surround sound to be implemented), and can also cope with interlaced video. MPEG-43 is building on the proven success of three fields: digital television, interactive graphics applications (synthetic content) and interactive multimedia (World Wide Web, distribution of and access to content). It will provide the standardised technological elements enabling the integration of the production, distribution and content access paradigms of the three fields. MPEG-4 is being developed for very low bandwidth connections, such as dial-up modems. The standard video frame size is 176x144 at 10 frames per second (it is optimised for video- conferencing). MPEG-4 is still under definition. A.4.3 T.120 The T.120 standard4 was approved by the ITU in 1995 and is aimed at the distributed sharing of documents and other forms of data, including virtual reality, gaming and real-time news subscription feeds. Document conferencing allows many users to make simultaneous changes to the one document without having to download the document 1 The document relating to the MPEG-1 standard has the ISO/IEC document number: 11172 (Nov 92) 2 The document relating to the MPEG-2 standard has the ISO/IEC document number: 13818 (Nov 94) 3 The document relating to the MPEG-4 standard has the ISO/IEC document number: 14496 (version 1 : Oct 98) 4 The document which defines the standard for T.120 can be viewed at http://www.itu.int. A license is required to gain access to the document. page 14 (60) © 1999 EURESCOM Participants in Project P913-GI
  27. 27. Deliverable 1 Volume 2: Annexes to a local storage medium. The T.120 standard will enable products from different vendors to interoperate, meaning that distributed document sharing can be achieved more readily. Document conferencing can be a very useful tool to use in conjunction with video and audio-conferencing, enabling users to discuss and modify documents online and in real-time. Document and application sharing is more sophisticated than whiteboard technology as it allows changes made by any of the users to be exported immediately to all hosts in the document conference. T.120 enables developers to easily create a multipoint domain and deliver data in real time with ease. Since T.120 is based on open standards, endpoint applications from multiple vendors can communicate freely. T.120 also specifies how applications may communicate via a number of network bridging products and services which support the T.120 standard. In multicast-capable networks, T.120 can deliver both reliable and unreliable data streams. The infrastructure of T.120 allows multicast and unicast to be used simultaneously, allowing a flexible solution to be developed for mixed unicast and multicast networks. The T.120 applications have complete transparency from the data transport mechanisms being used, and can run on a broad range of transport options, including PSTN, ISDN and IP. More importantly, these network transport types can co-exist in the same multipoint conference. T.120 applications can be used on almost all standard operating systems, including Microsoft Windows, UNIX, MAC-OS and OS-2 as well as a number of proprietary real-time operating systems. The implementation of the standard is not dependent upon the use of specific hardware, meaning that the standard can scale very well. Multipoint conferences can be set up without limitation on the logical network topology. Star topologies are likely to be most suitable, although many others could be more appropriate in certain circumstances. In complex multipoint conferences, the network topology which is adopted for the conference can have a significant effect on the performance and efficiency of the communication. T.120 can work alone or in unison with other ITU standards, such as the H.32x family of videoconferencing standards as well as the V-series of communications standards, and can also be extended to support new standards and transport types. The architecture of T.120 is multi-layered with well-defined protocols between layers. It should be noted that not many commercially available products are fully T.120 compliant. While many vendors claim to be T.120 compliant, there are still many interworking problems. The overview of the architecture is shown in Figure 5. © 1999 EURESCOM Participants in Project P913-GI page 15 (60)
  28. 28. Volume 2: Annexes Deliverable 1 Figure 6: Architecture of T.1201 Layers T.122, T.123, T.124 and T.125 specify an application-independent mechanism for providing multipoint data communication to services which support the facilities. Layers T.126 and T.127 define protocols for specific conferencing applications. A.4.4 Other standards2 There are a number of other standards which are directly or indirectly relevant to real- time services on the Internet. One of the most important technologies for transmitting audio data over low-bandwidth links is Adaptive Differential Pulse Code Modulation (ADPCM). ADPCM utilises the fact that there is usually only a very small amplitude difference between consecutive samples of an audio wave, assuming the wave is sampled at the correct rate. Instead of assigning 8-bit codes to each sample individually, it is possible to assign an 8-bit code to one sample and then encode the amplitude difference between this sample and the next sample(s). This can result in significant reductions in the amount of data requiring to be sent. 1 Image taken from http://gw.databeam.com/ccts/t120primer.html 2 Content adapted directly from http://www.itu.int/itudoc/itu-t/rec/g/g700-799/s_g727_e_38919.html and http://www.itu.int/itudoc/itu-t/rec/g/g700-799/s_g726_e_38918.html. page 16 (60) © 1999 EURESCOM Participants in Project P913-GI
  29. 29. Deliverable 1 Volume 2: Annexes The G.726 standard published by the ITU sets out the characteristics for the conversion of a 64 kbit/s A-law or µ-law pulse code modulation (PCM) channel to and from a 40, 32, 24 or 16 kbit/s ADPCM channel. The conversion is applied to the PCM bit stream using an ADPCM transcoding technique. Real-time applications which are bandwidth restricted can use 16, 20 and 40 kbit/s channels for carrying voice at different levels of quality. ITU Recommendation G.726 provides an outline description of the ADPCM transcoding algorithm, and provides the principles and functional descriptions of the ADPCM encoding and decoding algorithms respectively. Networking aspects and digital test sequences are also addressed by Recommendation G.726. ITU standard G.727 contains the specification of ADPCM algorithms with 5-, 4-, 3- and 2-bits per sample (i.e., at rates of 40, 32, 24 and 16 kbit/s). The characteristics indicated are recommended for the conversion of 64 kbit/s A-law or µ-law PCM channels to/ from variable rate-embedded ADPCM channels. Recommendation G.727 defines the transcoding law when the source signal is a pulse-code modulation signal at a pulse rate of 64 kbit/s developed from analogue voice frequency signals (i.e. normal PCM telephony). Applications where the encoder is aware and the decoder is not aware of the way in which the ADPCM codeword bits have been altered, or when both the encoder and decoder are aware of the ways the codewords are altered, or where neither the encoder nor the decoder are aware of the ways in which the bits have been altered can benefit from other embedded ADPCM algorithms. The embedded ADPCM algorithms specified in Recommendation G.727 are extensions of the ADPCM algorithms defined in Recommendation G.726 and are recommended for use in packetised speech systems operating according to the Packetised Voice Protocol (PVP) specified in draft Recommendation G.764. PVP is able to relieve congestion by modifying the size of a speech packet when the need arises. Utilising the embedded property of the algorithm described here, the least significant bit(s) of each codeword can be disregarded at packetisation points and/or intermediate nodes to relieve congestion. This provides for significantly better performance than by dropping packets during congestion. Recommendation G.727 first outlines a description of the ADPCM transcoding algorithm. It then provides the principles and functional descriptions of the ADPCM encoding and decoding algorithms, respectively. It contains also the computational details of the algorithm. A.5 Proprietary Encoding Schemes While many applications adopt internationally standardised encoding standards, such as MPEG and H.323, there are many other applications which use encoding schemes which are unique to the producer of the application. Many of these encoding schemes are very widely used. This section discusses some of these schemes and the standards that define them. A.5.1 RealNetwork’s RealSystem G21 RealSystem G2 is a streaming solution that was developed by RealNetworks. It offers the ability to stream media to users over most types of networks, and over all bandwidths. It is an open, standards based platform which can deal with many media types simultaneously. The codecs used by G2 can offer good quality at all bit rates, even under lossy network conditions. RealVideo and RealAudio files can automatically scale to bandwidths between 14.4 kb/s and 56 kb/s, and the bit rate is 1 See Annex B.1.1 for description about this product © 1999 EURESCOM Participants in Project P913-GI page 17 (60)
  30. 30. Volume 2: Annexes Deliverable 1 dynamically adjusted to match the available bandwidth using RealSystems SureStream technology. RealSystem G2 implements RTSP, the client/server protocol which is used to provide services such as pausing, fast-forward and rewind of streaming media. Synchronised Multimedia Integration Language (SMIL), a language developed for laying out and choreographing multimedia presentations is also implemented. RealSystem supports RealNetworks proprietary file formats as well as many standard and third party file formats including VRML, MIDI, MPEG, AVI, WAV, ASF, VIVO, and AU among others. A.5.2 Microsoft NetShow and Active Streaming Format1 Microsoft’s NetShow can give very good delivery of multimedia over a range of networks, from low bit-rate modems up to very high-speed LANs. NetShow supports a very wide range of audio and video codecs. NetShow itself refers to the software which usually resides on the media server. The files used by NetShow are Active Streaming Files (ASF) and these files are played back using Microsoft’s Windows Media Player. NetShow supports true media streaming. If the performance of the network degenerates, the NetShow compensates by automatically sending less video data to ensure continuous media playback (albeit at a lower quality level). Video playback may cease completely in circumstances of severe network congestion, leaving only the audio stream playing back. NetShow supports codecs for G.723, MPEG-1 layer 3, MPEG-4, H.263 among many others. A.5.3 Apple QuickTime2 QuickTime is a multi-platform industry-standard multimedia software architecture which was developed by Apple Computers. It can be used to develop and publish synchronised graphics, video, text, music, virtual reality and 3-dimensional media. QuickTime supports a range of media delivery mechanisms, from the Internet to DVD-ROM. Some of the key components in QuickTime’s success are its ease-of-use, wide availability and the fact that it can be downloaded and installed free of charge. Also, any FTP or HTTP web-server can support QuickTime’s ′progressive download′ mechanism. At present, there is no dedicated QuickTime server software to enable QuickTime to support true media streaming or live webcasting. QuickTime supports many codecs and file formats for video, audio, text, still images, animation and 3D. A.6 Coding Techniques Description A.6.1 Layered Coding Layered coding of video or audio streams creates a compressed bitstream with a base layer and one or more associated enhancement layers. The base layer bitstream is decoded separately and the enhancement layers can be decoded in conjunction with the base layer to provide an increase in the perceived quality of the video or audio presentation. Layered coding enables video and audio streams to be scaled well. 1 See Annex B.1.2 for description about this product 2 See Annex B.1.5 for description about this product page 18 (60) © 1999 EURESCOM Participants in Project P913-GI
  31. 31. Deliverable 1 Volume 2: Annexes A client can receive as many layers as it wants, depending on the available bandwidth. A client with a low-capacity connection can opt to receive only the base layer while a client with a high-speed connection can choose to receive some additional layers and receive a higher quality video/audio presentation. The server can therefore meet the requirements of many types of clients without needing to know each client’s specific capabilities. Many encoding standards are capable of performing layered coding. H.263 for example allows for 15 layers. A.6.2 Redundant Coding Modern data compression techniques can exploit the redundancy in a bit stream to reduce the raw data rate by a significant factor. However, when a data stream is compressed to it‘s maximum level it becomes very difficult to detect when errors have occurred. In the English language, errors in normal sentences can usually be detected and compensated for quite easily due to the redundancy of the language. If this redundancy is removed (for instance by using abbreviations or anagrams) the ability to detect errors is significantly reduced. For example take the term ″Syncfronous Digitel Hierarcy″. There are three errors in this phrase, but it can still be interpreted correctly. However, had we used the three-letter abbreviation for the phrase (SDH), a single error could have made us completely misinterpret the message (PDH, SDU etc). Redundancy coding uses the inherent redundancy in digital data streams to help the receiving client recover from transmission errors in the data stream which it receives. Hamming Coding1 and Cyclic Redundancy Checking are both examples of redundant coding schemes. With Hamming Coding, the bitstream is split up into codewords, and extra check-bits are added into the codeword to enable detection and correction of a certain number of errors. The number of errors which can be detected and corrected is dependent upon the number of check bits which are added to the codeword. The use of these check bits requires more overall bandwidth to transmit the message, but means that the receiver can recover from both single and burst errors which occur during transmission. For real-time applications where retransmissions can not be made, redundancy coding is an ideal way to help ensure error resilience. A.6.3 Transcoding A transcoder can be thought of as a device which can change the type of encoding used and/or the data rate between the input bitstream and the output bitstream. The input can be encoded with one compression algorithm, and the transcoder can convert it into another compression format, or can output the bitstream with the same format. Similarly, the input can have one data rate and the transcoder can convert it to a higher or a lower data rate. Conversion to lower bit rates is more common, as it is difficult to recover information after it has been discarded. Transcoders can be used at network boundaries to reduce the delivery rate of video or audio data to prevent overwhelming the network or the receiving client. Transcoders can also be used when there is not sufficient network resource to transmit a video or audio stream to a section of the network. If the data rate of the media cannot be reduced, the only other option is to lose data, since real-time data cannot be delayed significantly without serious degradation to the media presentation. Thus, transcoders can play a crucial role in ensuring real-time data streams can continue even when the network is congested, or when there is insufficient bandwidth available. 1 Hamming Coding and Cyclic Redundancy Coding are quite complex algorithms. Refer to ″Digital Communications: Fundamentals and Applications″, by Bernard Sklar, Prentice Hall International, ISBN 0-13-212713-X. © 1999 EURESCOM Participants in Project P913-GI page 19 (60)
  32. 32. Volume 2: Annexes Deliverable 1 Annex B: Review on tools & commercial products In the last few years, driven by the huge development of Internet’s use, lots of audio/video streaming and telephony/conferencing applications have appeared on the market. This section does a review of several commercial and non-commercial products for both best effort and bandwidth controlled environments. This review is organised on two sections, focusing streaming and conversational applications. As a result, at the end, this section will present feature tables for each of the application group analysis. B.1 Applications audio/video streaming Several commercial and freeware/shareware audio/video streaming products are available nowadays, presenting lots features and a great variety of authoring, diagnostic and content administration tools. On the negative side, the general lack of use of standards and the number of proprietary solutions represents a big question to be addressed to users and service providers on which is the best solution, since most of them are not interoperable. This review includes a summarised description of several applications and tools, and presents for each one of them a list of features such as: • Audio, video or A/V capability • Operating systems supported • Audio/video codecs supported • Minimum bandwidth required for audio/video • Delivery mechanisms (from application layer to IP layer) • Multicast support • Firewall support • Monitoring tools • Server features, including scalability, number of clients, input media sources supported etc • Client features (standalone, browser plug in, integration with other Internet services) • Content handling tools • Level of compliance with IETF Standards • Price range B.1.1 RealAudio/Real Video http://www.real.com RealAudio/RealVideo (currently on version G2) is a cross platform audio-video solution built on the industry standard protocol for streaming media, RTSP and on the file format SMIL (Synchronised Multimedia Integration Language). RealVideo introduces some compression technologies for video and audio offering a higher quality than its predecessors (Real Video 5 and below). The full-motion video codecs page 20 (60) © 1999 EURESCOM Participants in Project P913-GI
  33. 33. Deliverable 1 Volume 2: Annexes are scaleable for all bit rates and optimised for the three most prevalent (US) Internet connection speeds of 28.8 Kbps, 56 Kbps and 112 Kbps. Real Video's codec- independent open architecture supports installable compression algorithms as add-ons called "plug-ins" to its native codecs: RealVideo Standard (developed by RealNetworks) and RealVideo Fractal (using Clear Video technology from Iterated Systems, Inc (http://www.iterated.com/)). These "plug-ins" may be proposed by companies (e.g. DigitalBitCasting for MPEG1, MPEG2 and MP3 "rendering" plug-in on the player side and "File Format" plug-in on the server side) or be developed with the SDK. Clickable Video Maps are another feature that allow the user to interact with a video presentation. A mouse click on a region within the video image can cause a new clip to be played, seek within the current clip, or send a URL to the Web browser through Synchronised Multimedia. Regions are made interactive using an extension of the image-map standard with the added dimension of time. The RealPlayer also supports interactivity through embedded ActiveX and Netscape Plug-In controls that support JavaScript and VBScript. A proprietary mechanism called "adaptive stream management" allows the RealServer to identify the streaming rate consistent with the available bandwidth between the Server and the Player. In the case of files encoded with the proprietary "sure stream" mechanism, the server switches from one rate to another in a transparent way from the Player. Concerning the server administration, an HTTP session on a given port is established between the WEB server and the RealServer. Some Monitoring tools are also available for analysing the log reports of the RealServer. Stream Types Audio & Video Supported OS Windows (95/98 and NT), MacOS and UNIX (Linux and Solaris 2.5/2.6) Codecs Video: Proprietary RealVideo (standard and fractal) + MPEG-1 Audio: RealAudio proprietary + MPEG-1 Possibility to extend the list of supported codecs adding the "rendering" (on the player side) and "file format" (on the server side) plug-ins relative to a given AV encoding. For live encoding, it may also be necessary to upgrade the RealProducer (or to define a new one). Min. bandwidth Video+Audio: 20 Kbps Audio: 6.5-8.5 Kbps for voice and 8-12 Kbps for music quality Delivery HTTP, TCP, UDP+RDP (proprietary) and UDP+RTP methods Multicast mechanism supported (incl. MBONE)1 RTSP for unicast and "back-channel" multicast flow control Possibility to endlessly stream a "pre-recorded" file on an infinite loop using the g2slta mechanism Firewall support Yes Client features Standalone player + browser plug in + ActiveX control Stream feeds From server stored files or from real time encoding server Steaming text Possibility to stream text (e.g. slides) using the RealText format. 1 2 Multicast modes are implemented : - The "Back-channel" mode where a TCP session is maintained between the player and the server all along the streaming session. - The "Scaleable" mode which is the standardised Multicast mode implementing the SAP/SDP and RTP/RTCP standards protocols. In this mode, the player requests the SDP file of the multicast session from the RealServer using HTTP. © 1999 EURESCOM Participants in Project P913-GI page 21 (60)

×