Quality of Service for Streamed Multimedia over the Internet

Size: px
Start display at page:

Download "Quality of Service for Streamed Multimedia over the Internet"

Transcription

1 Quality of Service for Streamed Multimedia over the Internet Nicola Cranley*, Ludovic Fiard, Liam Murphy* *Performance Engineering Laboratory, School of Electronic Engineering, Dublin City University, Ireland Broadcom Eireann Research Ltd, Dublin, Ireland 1. Introduction Multimedia is any combination of text, graphics, audio, video, animation and data. Multimedia applications over the Internet include Video on Demand (VoD), interactive video, and videoconferencing. However there are limitations to these applications, as it is often required that a multimedia file be completely downloaded before it can be played or viewed. Streaming is the ability to start processing data before all of it has arrived, thus making delivery in real-time or near real-time possible. Streaming technologies are designed to overcome the problem of limited bandwidth. The implication of this is that multimedia files of any size can be played/displayed over the Internet in real-time or near real-time. To date, there has been no definitive way to transmit streamed MPEG-4 files across the Internet with an associated Quality of Service. One possibility is to write a control protocol on top of TCP/IP, which manages the flow of multimedia data [1]. In this paper, an alternative approach using a protocol stack comprising a Real-time Transport Protocol (RTP) layer over a User Datagram Protocol (UDP)/Internet Protocol (IP) layer is described. Firstly we provide a brief description of MPEG/MPEG-4 and RTP/RTCP, followed by a description of the system implemented and plans for its future development Quality of Service (QoS) In computer and telecommunications networks, Quality of Service (QoS) refers to the network operators commitment to providing and maintaining acceptable values of parameters or characteristics of user applications. In certain cases the network operator may be able to guarantee (perhaps probabilistically) the QoS level a given user's application will receive. This is of particular concern for the continuous transmission of high-bandwidth video and multimedia information. QoS can be characterised by a number of specific parameters, such as throughput, delay, delay variation, loss rate, and so on. The client specifies its desired QoS parameters when it requests a connection to a server. The client and server must agree on what constitutes acceptable service. Both the desired and minimum acceptable values may be exchanged and negotiated. If the client and server cannot agree on these QoS parameters then the connection is refused. This may happen if the server is already heavily loaded with existing connections, since the server's first priority is to maintain the QoS of already-accepted connections. Providing QoS guarantees is difficult or impossible in networks that offer "best effort" service, such as the Internet's IP layer. Therefore a lot of work has been carried out recently on how to add QoS support to the Internet service model. Examples of this include the intserv (Integrated Services) [2] and diffserv (Differentiated Services) [3] approaches. The RTP/RTCP approach is an attempt to add QoS support mechanisms above the Transport layer (TCP or UDP). However the use of RTCP messages to provide and maintain QoS guarantees to multimedia streams is still under investigation. 2. MPEG/MPEG-4 The term MPEG stands for Motion Picture Experts Group, the body that standardised the MPEG formats (syntax and semantics) [4]. MPEG is a standardised method of compressing video and is used in many current and emerging products. It is at the heart of television set top boxes, DSS, HDTV decoders, DVD players, video conferencing, Internet video and other applications. High compression is needed so that less storage space is required for archived video information, and/or it occupies less bandwidth in transmission of the video information from one point to another. There have been a number of MPEG standards defined, each for a specific application context. For example MPEG-1 was designed specifically to store movies on CD-ROM in CD-I and CD-Video format. MPEG-4 is a new standard designed for video conferencing and other video applications [5]. Unlike MPEG-1 where a video sequence is decomposed into

2 frames, MPEG-4 decomposes the scene into objects, called audio-visual objects (AVO s), each with its own audio and video track that will vary over time. MPEG-4 is very flexible, for example, if the network is congested or overloaded, not all the objects need to be sent to the client, only those that make the video sequence coherent. For example, a simple video clip of a newsreader will have two objects, the newsreader and the background. If the network is overloaded, the background information can be discarded to ensure that the video sequence is transmitted to the client on time and coherently. Previously using other MPEG standards, the image would flicker or be noticeably delayed. Media aware Delivery unaware COMPRESSION LAYER AVO BIF OD ES ES Interface AU Media and Delivery unaware DMIF Application Interface SYNC LAYER (SL) ES stream management and synchronisation SL strea SL-PDU Media unaware Delivery aware DELIVERY LAYER (DMIF) Flexmultiplexing of SL streams and transport access to the delivery technology FlexMux Fig.1. MPEG-4 layered architecture Internet RTP/UDP/IP The Compression Layer produces the compressed representation of the traditional audio/visual elementary streams (ES) and associated streams such as the Binary Format for Scenes (Bifs), object descriptors (OD) and initial object descriptors (IOD) that compose a scene. The Bifs ES syntax allows dynamic scene description. The OD ES syntax allows the description of hierarchical relations, location and properties of the different ES s through a dynamic set of OD s. OD s refer to natural or synthetic objects and serves as a grouping of one or more Elementary Stream Descriptors that refer to a single media object. A complete set of OD s can be seen as an MPEG-4 resource or session description. The compressed content produced by the compression layer is organised into Elementary Streams. This layer provides the synchronisation between the ES s. ES s are organised into Access Units (AU). The AU is the smallest element to which a timestamp can be attributed and each AU is unique. AU s produced by the encoders are passed onto the SL layer either complete or segmented i.e. partial AU s through the Elementary Stream Interface (ESI). Each AU is marked with indications of its boundaries, random access points and timestamps such as the desired decoding time, arrival time and composition time of the decoded AU. The Synchronisation Layer takes these AU s and encapsulates them into SL packets or SL-PDU s (packet data units). The SL packet header can be adapted to the needs of the ES to be carried and provides a means for continuity checking in case of data loss, carrying a coded representation of the timestamps and

3 associated information. The configuration of each individual SL packet header is conveyed in the SLConfigDescriptor. The SL-PDU s of varying instantaneous bit rates can be multiplexed or interleaved by means of the FlexMux tool. The use of a FlexMux tool is optional which adds a low multiplexing overhead to the multiplexed SL streams. A FlexMux stream is a succession of FlexMux packets. Each FlexMux packet is built from a fixed length FlexMux packet header and a FlexMux payload. The FlexMux packet header is composed of a one-byte index followed by a one-byte length field. There are two FlexMux packet management modes, MuxCode Mode or Simple Mode. In Simple Mode, the FlexMux packet payload corresponds to one complete SL packet. In MuxCode Mode, the FlexMux payload can consist of a number of SL packets. FlexMux describes the bitstream syntax used to multiplex SL streams. It also is used for the reconstruction of the correct timing of an MPEG-4 bitstream and is supported by the MPEG-4 SL stream syntax and the MPEG-4 FlexMux stream syntax. The reconstruction of correct timing of an MPEG-4 FlexMux stream is possible under some QoS constraints closely related to the reduction of network jitter. MPEG-4 FlexMux assumes that there is a nearly constant transmission delay. The MPEG-4 Delivery Application Interface supports content location independent protocols firstly, for establishing the MPEG-4 session and secondly for accessing to transport channels. The DMIF monitors transport channels on the QoS requirements assigned to the SL streams, and support the multiplexing of the SL streams, by means of the FlexMux tool. 3. RTP/RTCP(Real time Transport Protocol/ RTP Control Protocol) The main problem with UDP/IP as a transport mechanism is that there is no guarantee that the packets will arrive, and once lost or delayed past their playtime they are discarded. However using another transport mechanism such as TCP/IP would be wasteful, as it has a larger header overhead and requests retransmission of all lost or delayed packets. Retransmission of all lost packets is usually unsuitable for real-time applications, as this would cause undue traffic on the network and the retransmitted packets may arrive too late for play-out. So far there are no standards in existence for requesting the re-transmission of streamed media. RTP is a transport protocol designed for real-time applications [6]. RTP has been used with other network protocols such AAL5/IP and TCP/IP, but applications typically run RTP on top of UDP/IP to make use of UDP's multiplexing and checksum facilities. RTP and RTCP are independent of the underlying transport and network. RTP and RTCP add extra functionality to UDP/IP such as sequence numbers and timestamps. RTCP is particularly useful as it enables the integration of some quality of service mechanisms by means of client feedback, thus allowing the server to modify its transmission to the client in response to network conditions. In essence, it is the clients feedback which dictates the servers transmission. The MPEG-4 data is broken up into packets constituting the payload of the RTP/UDP/IP packets. Each layer in the stack adds a header of information so that the packets can be routed to, and decoded by, the client who has requested it. RTP should be able to adjust its transmission to match the receivers requirements and abilities and network conditions. However in multicast sessions it is difficult for the server to determine how it should adapt - to the average of the users, or to the lowest common denominator, or the highest. Instead, the client controls rate adaptation by combining layered encoding with layered transmission. RTP provides end-to-end network transport functions suitable for applications transmitting realtime data, such as audio or video, over multicast or unicast network services. There is no guarantee ensuring timely delivery or QoS, nor does RTP provide multiplexing/de-multiplexing facilities. RTP does not assume that packets will arrive in sequence and so it incorporates packet sequence numbers within its header so that the receiver can sort the sender's packet sequence before decoding. The RTP payload is the data transported by the RTP packet, which in this case is the MPEG-4 systems data. An RTP packet consists of a fixed header, a list of contributing sources and the payload data. Typically one RTP packet is encapsulated within one UDP/IP packet. RTP should use an even destination port number and the corresponding RTCP stream should use the next higher (odd) destination port number. In a unicast session, both participants need to identify a port pair for receiving RTP and RTCP packets. When RTP data is sent in both directions, each participant must issue RTCP Sender Reports. However it cannot be assumed that the source of incoming RTP data will be the destination for outgoing RTP data. The Synchronisation source (SSRC) is the source of a stream of RTP packets. All packets from the same source share the same timing and sequence numbering space. This is important for video-conferencing, as

4 there will be data from many different sources such as the microphones, cameras etc. A synchronisation source can change its data format over time. The SSRC is just a 32-bit random number but will be globally unique throughout the RTP session. The SSRC identifiers are bound through the RTCP information. The Contributing source (CSRC) is the source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer. For example in an audio conference, several peoples' speech will be interleaved into one RTP packet, the CSRC will identify whose speech was combined and identifying who the current speaker is. The fields in the RTP packet header that are of interest are the extension bit and the marker bit. When the extension bit is set, denoted X in Fig.2, indicates that the fixed header must be followed by one header extension. It is through extending and tailoring this header that QoS will be integrated into RTP. Also, the marker bit, denoted M in Fig.2, is of interest as the interpretation of the marker bit can be defined by a profile. Markers are used to allow significant events such as frame boundaries to be marked in the packet stream. A profile may define additional marker bits, or specify that there is no marker bit, by changing the number of bits in the payload type field. In the system we have implemented this marker bit is assumed to indicate packet priority V P X CC M PT Sequence Number TIMESTAMP Synchronisation source (SSRC) identifier Contributing source (CSRC) identifier Fig.2. RTP Packet Structure It is possible to multiplex RTP sessions although the number of multiplexing points should be minimised. In RTP, multiplexing is provided by the destination address (network address and port number) which define the RTP session. In the case of audio-video conferences where audio and video are encoded separately, one RTP channel must be set up for the audio stream and another for the video stream, each with its own destination transport address in addition to the RTCP channel. The audio and video streams are transmitted and treated separately but they share the same canonical name identifying them so that they can be associated with each other at the receiver. The RTP header is flexible and can be adapted for profile specific modifications and additions. This facility is provided by the extension mechanism. However the header extension is intended for limited use only. If the extension bit is set to 1, this indicates that there is a variable length header appended to the RTP header, following the CSRC list. RTP receivers provide quality feedback using the RTCP report packets. RTCP is used to facilitate the monitoring of RTP data delivery and quality of service throughout the session. RTCP is used to convey statistics about the transmission to the client and server periodically [7]. RTCP performs four main functions: - 1. Provide feedback on the quality of the data distribution. This feedback could be used directly to enable the server to dynamically adapt its transmission and also to aid the diagnosis of problems on the network by re-routing the RTCP packets to a third party. 2. RTCP has a persistent transport-level identifier for an RTP source called the canonical name. This name or CNAME is used to keep track of all the participants within the session. The CNAME is also required to associate multiple data streams and then synchronise them together for example audio and video streams. 3. In the case of conferencing, all participants send RTCP packets to all other participants; each participant can independently observe all the other participants. 4. Convey minimal session control information. Each RTCP packet begins with a fixed header part followed by structured elements that may be of variable length. RTCP packets are stackable and so multiple RTCP packets can be concatenated without the need of a separator forming an RTCP compound packet, which is then encapsulated in a UDP/IP packet.

5 RTCP is designed to carry a variety of control information. The Sender Report (SR) is used for the transmission and reception of statistics from participants that are also active senders. The Receiver Report (RR) is used for the reception of statistics from the participants that are not active senders and used in combination with SR for active senders reporting on more than 31 sources. The Source DEScription (SDES) items identifying the source using a canonical name (CNAME). The APPlication (APP) packet is profile defined and specific to the session type. There are, however, a few restraints on RTCP: 1. Reception statistics (SR and RR) should be sent as often as possible, therefore each periodically transmitted compound RTCP packet must include a report packet. 2. New receivers need to receive a CNAME for a source as soon as possible to identify the source and to begin associating media. A compound RTCP packet must also include the SDES CNAME. So RTCP packets must be sent in a compound packet of at least one SR and one RR, with one SDES packet. V RR[#site1, #site2] SR[#site1, #site2] SDES #CNAME phone #CNAME loc BYE##why Fig.3. RTCP Compound Packet Structure Control traffic is not self-limiting and if there are many participants in a session all transmitted control packets at the same time causing undue congestion on the network. This is prevented by dynamically adapting the RTCP transmission interval. It is recommended that the control traffic should be limited to one RTCP packet approximately every 5 seconds, although this interval may be scaled to suit network conditions. For example, if the network is highly loaded, then the interval could be scaled down. Sender and Receiver reports differ in that the Sender Reports include a 20-byte sender information section for use by active senders. 3.1 Extensions to the RTP and RTCP payload type format enabling Quality of Service The main objective is to adapt RTP to lower delay requirements for streaming applications by making RTP more reliable, in a sense emulating TCP through selective re-transmissions. In order to realise this the existing RTP/RTCP payload format must be modified slightly. The underlying transport protocol chosen is UDP/IP (user datagram protocol/internet protocol) which is extremely unreliable and is susceptible to severe packet loss when transmitting compressed MPEG video streams in congested networks. One simple solution is to use increased redundancy by sending multiple copies of data packets, however this adds an extra load on the network. Another solution using retransmission of all lost packets is unsuitable for real-time or near real-time streams, as retransmitting causes additional propagation delays and also increases the load on the network PA PT PR DTI SNHP Diff Time Stamp NULL padding Fig.4. RTP header extension for Selective Retransmission V P RXP PT=Rreq Length SSRC C1 SNHP1 C2 SNHP2 Fig.5. RTCP header extension for Selective Retransmission The fields of interest in Fig.4 of the RTP header extension are the priority bit, denoted PR, and the Sequence Number of RTP packet with High Priority, denoted SNHP. The Priority (PR) bit identifies the priority of the RTP packet, which will be assumed to be equal to the existing marker bit in the system

6 implemented. If set it indicates the presence of a data packet with a high priority. The Sequence Number of RTP packet with High Priority (SNHP) indicates the sequence number of the RTP packet with high priority. This number increases with each high priority packet sent. If the PR bit is not set, then this field indicates the sequence number of the last high priority packet sent, thus allowing a log to be kept of all the high priority packets sent in all packets sent, both of high and low priority. In the RTCP header extension, Fig.5, the field of interest is the retransmission protocol, denoted RXP, and the Control bits, denoted C1. RXP indicates the re-transmission protocol to be used. The Control bits indicate the number of packets lost and when used in conjunction with the SNHP fields identify which packets in the sequence were lost. In the case of MPEG-4 systems streams certain packets are more important than others so, instead of arbitrarily re-transmitting all lost packets, the approach is to selectively re-transmit lost packets that have a high importance to the coherence, decoding and playout of the MPEG-4 stream. The priority bit (PR) in the RTP extension is used to indicate a packet of high priority; however this can only indicate two levels of priority. Detection of a lost high priority packet is a straightforward matter of comparing the SNHP of the recently received packet with the client s log of high priority packets received. This will reduce the number of retransmissions requested. There is also a retransmission judgement whereby the client will estimate whether the retransmission request of the important packet will arrive in time for playout. There can also be multiple retransmission attempts based on the retransmission judgement. Requesting a retransmission should be avoided but, if it is necessary, the client should estimate the round-trip propagation delay between the sending the retransmission request and receiving the requested retransmitted packet. As mentioned earlier, the RTCP interval is set to approximately sending one RTCP packet every 5 seconds. This value is not fixed as, if all receivers in a multicast session were to transmit their control packets at the same time, this could cause flooding at the sever side. In the unicast scenario this is unsuitable as the request for the retransmission of lost packets could take up to 5 seconds and would be useless for real-time or near realtime applications as the retransmitted packet would arrive after the playout time. The RTCP interval should be dynamically adaptable to signal severe packet loss to the server as soon as possible, indicating that there are problems with the network. 3.2 Using RTP as a transport mechanism for MPEG-4 FlexMux stream MPEG-4 applications can involve a large number of ES s and thus a large number of RTP sessions. Allowing a selective bundling scheme or multiplexing of ES s may be necessary for certain MPEG-4 applications. MPEG-4 FlexMux streams can be synchronised with other RTP payloads. MPEG-4 FlexMux streams and other real-time data streams can be combined into a set of consolidated streams through the use of RTP mixers and translators. The delivery performance of the MPEG-4 stream can be monitored via the RTCP control channel. An MPEG-4 FlexMux stream is mapped directly to the RTP payload without any addition of extra header fields or the removal of any FlexMux packet header. Each RTP packet contains a sender clock reference timestamp that is used to synchronise the FlexMux clock. On the client side, the FlexDemultiplexor does not make use of the RTP timestamp. The purpose of the RTP timestamp is to determine the network jitter, and propagation delay between server and client. An RTP packet should begin with an integer number of FlexMux packets. 4. System Implementation The overall system is implemented using a client-server architecture, as shown in Figure 6. The server architecture consists of four main components: the source for MPEG-4 data; a translator; an MPEG/RTP interface; and the RTP/UDP interface. The main function of these is to take the MPEG-4 source data and package the information into UDP packets, which are then transmitted to the client over the Internet. The client architecture is the inverse of the server as it must extract the MPEG-4 data from the packets by removing the header appended by each layer in the server stack so that it can extract the stream file. Three programs have been written in C++ (the client, the server and the multiplexor) to implement the system and have been tested using a local loop on one PC. As there is no player available yet to decode the transmitted MPEG-4 file on the client side, playback of the transmitted video is not yet possible. To ensure the stream file is transmitted correctly to the client, the sequence numbers and timestamps of the transmitted RTP packets and the statistics conveyed through the RTCP packets are monitored on both the

7 client and server side. The statistics collected by the server about the client are: the fraction of packets lost; the cumulative number of packets lost; the highest sequence number of the last received packet; the jitter; the timestamp of the last reception report; the reception time of the last reception report; and the time of the reception report. The server uses these statistics to dynamically adapt its transmission to optimise the use of network resources and improve the quality of the received file for the client. The statistics collected on the client side about the server are the number of packets received and the cumulative number of bytes contained in the packets received. The statistics collected about the server are not as important as those collected by the server about the client; after all, it is the client who is in the better position to judge the QoS. The translator program is based on the bifs-encoder and multiplexer developed by CSELT [2] for offline encoding of the MPEG-4 source data. This translator program is slightly modified to produce the FlexMux packets with reduced SL-header i.e. duplicated fields are removed. The program reads the MPEG-4 source data from a text file and a script file and produces several files. These files are the encoded and packetised version of the MPEG-4 source data and are comprised of AVO (audiovisual object) files, the scene description files (BIFS and OD) and the IOD (initial object description) files. It creates the SL (Sync layer) packets and then removes the redundant data (i.e. fields duplicated in the RTP header). These SL-PDU s are then multiplexed using the FlexMux tool operating in Mux Code Mode. The output of the translator program is a muxrtp file. This muxrtp file is the input to the server program, which reads the data in the muxrtp file and creates an RTP packet for each muxrtp packet. Also developed is an interface program, which decodes the headers of the FlexMux packets. Normal system operation is as follows. The client requests an MPEG-4 stream file to be played from the server over a reliable TCP/IP connection. The server acknowledges the file request and spawns two duplex UDP connections between the client and the server for both the RTP channel and RTCP channel. FlexMux Translator program Muxer BIFS-ENCoder File. MUXRTP File. MP4 File. BIF File. OD File. LST Server MUXRTP file MPEG/RTP interface RTP/RTCP Client Muxrtp file MPEG/RTP interface RTP/RTCP Real Time Application Decoder/Player Multiplexor De-multiplexor MPEG-4 source File.TXT, File.SCR MPEG RTP UDP/IP Payload header header Fig.6. System overview RTCP RTCP UDP/IP Payload header header Within the server there are three main threads. The use of threads ensures that the functionality between the different processing elements of the program can work simultaneously and with nearindependence. The first thread creates and transmits the RTP packets until the end of the file is reached or until the client terminates the session. A mutex status variable is used to define a transmission profile; for example, one such profile sends just high priority packets. The RTP packets are then multiplexed and encapsulated into UDP packets and transmitted over the Internet to the client. The second thread loops periodically sending RTCP packets. The third thread loops until the end of the session, listening for RTCP packets from the client. When an RTCP packet is received from the client, the server extracts the relevant statistical information about the client. This information is used to modify the transmission profile to the client by way of locking the mutex status variable, changing its value if necessary, and releasing the lock. The new status value will then be imposed in the RTP transmission thread thus modifying the RTP transmission profile. On the receiving side there are three main threads in operation. One thread loops continuously until the end of the session or until the session is terminated, receiving the RTP packets, removing the UDP/IP header information to extract the RTP packet and subsequently the RTP header is removed and the

8 original muxrtp packet is extracted. These muxrtp packets are passed onto an MPEG-4 decoder that will play the MPEG-4 video stream. The second thread also loops until the end of the session or until the session is terminated receiving RTCP packets from the server. The third thread loops periodically sending RTCP packets to the server containing the clients reception statistics. 5. Future Development The current version of the system is capable of creating and transmitting the MPEG-4 stream file using a RTP/UDP/IP transport stack to a client. The next stage is to harness and exploit the characteristics of both the transport media and MPEG-4 so as to implement QoS parameters. The extensions to the RTP and RTCP packets have yet to be implemented with the intended purpose of implementing selective retransmission into the system [9]. The extended RTP and RTCP packets are to be used to monitor that the client receives all essential packets i.e. the PR bit is set to one. Currently, the server assumes that the marker bit and the priority bits are equal. The server can transmit according to different transmission profiles as defined by the status variable, however it is unable to dynamically change the transmission profile dynamically within the session. Also, research must be done to identify what characterises and constitutes a change in transmission profile. For example, when should the server resort to prioritised transmission of high priority packets, or when should it adopt transmission redundancy to send high priority packets? Ideally, prioritised encoding transmission (PET) should be adopted when the MPEG-4 file is encoded in real-time; however, in the system implemented, encoding of the MPEG-4 file is offline. Should any high priority packets be lost, this will be detected by comparing the SNHP field in the RTP packet. The modification to the system will be to use the RTCP packet to indicate to the server to modify its transmission to suit the capacity of the network. However if there is serious packet loss on the network, for example, ten consecutive high priority packets are lost, there is no way of signaling this to the server immediately. The client will automatically wait until the next RTCP interval has timed out before it can notify the server of this situation. Then there is no guarantee that the RTCP packet sent from the client will reach the server. RTCP packets are unsuitable for this type of urgent reporting back to the server as they are designed only for statistics reporting and are sent periodically. Therefore a profile-specific RTCP packet of a more urgent nature needs to be defined, being sent only when needed. There are many aspects of RTP that have yet to be defined and finalised, and so for the moment a basic draft version of the RTP packet is being used. References [1] G. Muntean and L. Murphy, An Object-Oriented Prototype System for Feedback Controlled Multimedia Networking, submitted to ISSC 2000 [2] [3] [4] The MPEG Home page [5] The MPEG-4 Forum Home page [6] RFC 1889: RTP: A transport protocol for Real Time Applications [7] RFC 1890: RTP profile for Audio and Video Conference with Minimal Control [8] Internet draft: draft-podolsky-avt-rtprx-00.txt A RTCP based Retransmission Protocol for Unicast RTP Streaming Multimedia

IP-Telephony Real-Time & Multimedia Protocols

IP-Telephony Real-Time & Multimedia Protocols IP-Telephony Real-Time & Multimedia Protocols Bernard Hammer Siemens AG, Munich Siemens AG 2001 1 Presentation Outline Media Transport RTP Stream Control RTCP RTSP Stream Description SDP 2 Real-Time Protocol

More information

Advanced Networking Voice over IP: RTP/RTCP The transport layer

Advanced Networking Voice over IP: RTP/RTCP The transport layer Advanced Networking Voice over IP: RTP/RTCP The transport layer Renato Lo Cigno Requirements For Real-Time Transmission Need to emulate conventional telephone system Isochronous output timing same with

More information

Voice over IP: RTP/RTCP The transport layer

Voice over IP: RTP/RTCP The transport layer Advanced Networking Voice over IP: /RTCP The transport layer Renato Lo Cigno Requirements For Real-Time Transmission Need to emulate conventional telephone system Isochronous output timing same with input

More information

Real Time Protocol (RTP)

Real Time Protocol (RTP) 1 Real Time Protocol (RTP) Prof. Jean-Yves Le Boudec Prof. Andrzej Duda Prof. Patrick Thiran LCA, EPFL CH-1015 Ecublens Patrick.Thiran@epfl.ch http://icawww.epfl.ch Multimedia applications 2 Streaming

More information

Streaming Audio and Video

Streaming Audio and Video Streaming Audio and Video CS 360 Internet Programming Daniel Zappala Brigham Young University Computer Science Department Streaming Audio and Video Daniel Zappala 1/27 Types of Streaming stored audio and

More information

Classes of multimedia Applications

Classes of multimedia Applications Classes of multimedia Applications Streaming Stored Audio and Video Streaming Live Audio and Video Real-Time Interactive Audio and Video Others Class: Streaming Stored Audio and Video The multimedia content

More information

Unit 23. RTP, VoIP. Shyam Parekh

Unit 23. RTP, VoIP. Shyam Parekh Unit 23 RTP, VoIP Shyam Parekh Contents: Real-time Transport Protocol (RTP) Purpose Protocol Stack RTP Header Real-time Transport Control Protocol (RTCP) Voice over IP (VoIP) Motivation H.323 SIP VoIP

More information

Digital Audio and Video Data

Digital Audio and Video Data Multimedia Networking Reading: Sections 3.1.2, 3.3, 4.5, and 6.5 CS-375: Computer Networks Dr. Thomas C. Bressoud 1 Digital Audio and Video Data 2 Challenges for Media Streaming Large volume of data Each

More information

Requirements of Voice in an IP Internetwork

Requirements of Voice in an IP Internetwork Requirements of Voice in an IP Internetwork Real-Time Voice in a Best-Effort IP Internetwork This topic lists problems associated with implementation of real-time voice traffic in a best-effort IP internetwork.

More information

Introduction to VoIP. 陳 懷 恩 博 士 副 教 授 兼 所 長 國 立 宜 蘭 大 學 資 訊 工 程 研 究 所 Email: wechen@niu.edu.tw TEL: 03-9357400 # 255

Introduction to VoIP. 陳 懷 恩 博 士 副 教 授 兼 所 長 國 立 宜 蘭 大 學 資 訊 工 程 研 究 所 Email: wechen@niu.edu.tw TEL: 03-9357400 # 255 Introduction to VoIP 陳 懷 恩 博 士 副 教 授 兼 所 長 國 立 宜 蘭 大 學 資 訊 工 程 研 究 所 Email: wechen@niu.edu.tw TEL: 3-93574 # 55 Outline Introduction VoIP Call Tpyes VoIP Equipments Speech and Codecs Transport Protocols

More information

RTP / RTCP. Announcements. Today s Lecture. RTP Info RTP (RFC 3550) I. Final Exam study guide online. Signup for project demos

RTP / RTCP. Announcements. Today s Lecture. RTP Info RTP (RFC 3550) I. Final Exam study guide online. Signup for project demos Announcements I. Final Exam study guide online RTP / RTCP Internet Protocols CSC / ECE 573 Fall, 2005 N. C. State University II. III. Signup for project demos Teaching evaluations at end today copyright

More information

Audio and Video for the Internet

Audio and Video for the Internet RTP Audio and Video for the Internet Colin Perkins TT rvaddison-wesley Boston San Francisco New York Toronto Montreal London Munich Paris Madrid Capetown Sydney 'lokyo Singapore Mexico City CONTENTS PREFACE

More information

point to point and point to multi point calls over IP

point to point and point to multi point calls over IP Helsinki University of Technology Department of Electrical and Communications Engineering Jarkko Kneckt point to point and point to multi point calls over IP Helsinki 27.11.2001 Supervisor: Instructor:

More information

Encapsulating Voice in IP Packets

Encapsulating Voice in IP Packets Encapsulating Voice in IP Packets Major VoIP Protocols This topic defines the major VoIP protocols and matches them with the seven layers of the OSI model. Major VoIP Protocols 15 The major VoIP protocols

More information

Transportation Protocols: UDP, TCP & RTP

Transportation Protocols: UDP, TCP & RTP Transportation Protocols: UDP, TCP & RTP Transportation Functions UDP (User Datagram Protocol) Port Number to Identify Different Applications Server and Client as well as Port TCP (Transmission Control

More information

Introduction to VoIP. 陳 懷 恩 博 士 助 理 教 授 兼 計 算 機 中 心 資 訊 網 路 組 組 長 國 立 宜 蘭 大 學 資 工 系 Email: wechen@niu.edu.tw TEL: 03-9357400 # 340

Introduction to VoIP. 陳 懷 恩 博 士 助 理 教 授 兼 計 算 機 中 心 資 訊 網 路 組 組 長 國 立 宜 蘭 大 學 資 工 系 Email: wechen@niu.edu.tw TEL: 03-9357400 # 340 Introduction to VoIP 陳 懷 恩 博 士 助 理 教 授 兼 計 算 機 中 心 資 訊 網 路 組 組 長 國 立 宜 蘭 大 學 資 工 系 Email: wechen@niu.edu.tw TEL: 3-93574 # 34 Outline Introduction VoIP Call Tpyes VoIP Equipments Speech and Codecs Transport

More information

2.1 Introduction. 2.2 Voice over IP (VoIP)

2.1 Introduction. 2.2 Voice over IP (VoIP) 2.1 Introduction In this section can provide the necessary background on the structure of VoIP applications and on their component, and the transmission protocols generally used in VoIP. 2.2 Voice over

More information

Multimedia Communications Voice over IP

Multimedia Communications Voice over IP Multimedia Communications Voice over IP Anandi Giridharan Electrical Communication Engineering, Indian Institute of Science, Bangalore 560012, India Voice over IP (Real time protocols) Internet Telephony

More information

Voice over IP. Presentation Outline. Objectives

Voice over IP. Presentation Outline. Objectives Voice over IP Professor Richard Harris Presentation Outline Brief overview of VoIP and applications Challenges of VoIP IP Support for Voice Protocols used for VoIP (current views) RTP RTCP RSVP H.323 Semester

More information

Broadband Networks. Prof. Dr. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Bombay. Lecture - 29.

Broadband Networks. Prof. Dr. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Bombay. Lecture - 29. Broadband Networks Prof. Dr. Abhay Karandikar Electrical Engineering Department Indian Institute of Technology, Bombay Lecture - 29 Voice over IP So, today we will discuss about voice over IP and internet

More information

Streaming Audio and Video

Streaming Audio and Video Streaming Audio and Video Multimedia on the Internet Daniel Zappala Brigham Young University Computer Science Department Streaming Audio and Video Daniel Zappala 1/39 1 Introduction 2 Stored Media 3 CDNs

More information

An architecture for the delivery. of DVB services over IP networks Rennes, January 2007 INTRODUCTION DIGITAL VIDEO TRANSPORT

An architecture for the delivery. of DVB services over IP networks Rennes, January 2007 INTRODUCTION DIGITAL VIDEO TRANSPORT An architecture for the delivery Datasheet User guide White paper þ of DVB services over IP networks Rennes, January 2007 INTRODUCTION Present paper proposes to look around technologies used today for

More information

159.334 Computer Networks. Voice over IP (VoIP) Professor Richard Harris School of Engineering and Advanced Technology (SEAT)

159.334 Computer Networks. Voice over IP (VoIP) Professor Richard Harris School of Engineering and Advanced Technology (SEAT) Voice over IP (VoIP) Professor Richard Harris School of Engineering and Advanced Technology (SEAT) Presentation Outline Basic IP phone set up The SIP protocol Computer Networks - 1/2 Learning Objectives

More information

Sources: Chapter 6 from. Computer Networking: A Top-Down Approach Featuring the Internet, by Kurose and Ross

Sources: Chapter 6 from. Computer Networking: A Top-Down Approach Featuring the Internet, by Kurose and Ross Multimedia Communication Multimedia Systems(Module 5 Lesson 2) Summary: H Internet Phone Example Making the Best use of Internet s Best-Effort Service. Sources: H Chapter 6 from Computer Networking: A

More information

An Introduction to VoIP Protocols

An Introduction to VoIP Protocols An Introduction to VoIP Protocols www.netqos.com Voice over IP (VoIP) offers the vision of a converged network carrying multiple types of traffic (voice, video, and data, to name a few). To carry out this

More information

Protocols and Architecture. Protocol Architecture.

Protocols and Architecture. Protocol Architecture. Protocols and Architecture Protocol Architecture. Layered structure of hardware and software to support exchange of data between systems/distributed applications Set of rules for transmission of data between

More information

Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme

Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme Chapter 2: Representation of Multimedia Data Chapter 3: Multimedia Systems Communication Aspects and Services Multimedia Applications and Communication Protocols Quality of Service and Resource Management

More information

TCP - Introduction. Features of TCP

TCP - Introduction. Features of TCP TCP - Introduction The Internet Protocol (IP) provides unreliable datagram service between hosts The Transmission Control Protocol (TCP) provides reliable data delivery It uses IP for datagram delivery

More information

Internet Services & Protocols Multimedia Applications, Voice over IP

Internet Services & Protocols Multimedia Applications, Voice over IP Department of Computer Science Institute for System Architecture, Chair for Computer Networks Internet Services & Protocols Multimedia Applications, Voice over IP Dr.-Ing. Stephan Groß Room: INF 3099 E-Mail:

More information

Transport Layer Protocols

Transport Layer Protocols Transport Layer Protocols Version. Transport layer performs two main tasks for the application layer by using the network layer. It provides end to end communication between two applications, and implements

More information

Voice over IP (VoIP) Overview. Introduction. David Feiner ACN 2004. Introduction VoIP & QoS H.323 SIP Comparison of H.323 and SIP Examples

Voice over IP (VoIP) Overview. Introduction. David Feiner ACN 2004. Introduction VoIP & QoS H.323 SIP Comparison of H.323 and SIP Examples Voice over IP (VoIP) David Feiner ACN 2004 Overview Introduction VoIP & QoS H.323 SIP Comparison of H.323 and SIP Examples Introduction Voice Calls are transmitted over Packet Switched Network instead

More information

Indepth Voice over IP and SIP Networking Course

Indepth Voice over IP and SIP Networking Course Introduction SIP is fast becoming the Voice over IP protocol of choice. During this 3-day course delegates will examine SIP technology and architecture and learn how a functioning VoIP service can be established.

More information

Module 6. Internetworking. Version 2 CSE IIT, Kharagpur

Module 6. Internetworking. Version 2 CSE IIT, Kharagpur Module 6 Internetworking Lesson 2 Internet Protocol (IP) Specific Instructional Objectives At the end of this lesson, the students will be able to: Explain the relationship between TCP/IP and OSI model

More information

Bandwidth Control in Multiple Video Windows Conferencing System Lee Hooi Sien, Dr.Sureswaran

Bandwidth Control in Multiple Video Windows Conferencing System Lee Hooi Sien, Dr.Sureswaran Bandwidth Control in Multiple Video Windows Conferencing System Lee Hooi Sien, Dr.Sureswaran Network Research Group, School of Computer Sciences Universiti Sains Malaysia11800 Penang, Malaysia Abstract

More information

Lecture 33. Streaming Media. Streaming Media. Real-Time. Streaming Stored Multimedia. Streaming Stored Multimedia

Lecture 33. Streaming Media. Streaming Media. Real-Time. Streaming Stored Multimedia. Streaming Stored Multimedia Streaming Media Lecture 33 Streaming Audio & Video April 20, 2005 Classes of applications: streaming stored video/audio streaming live video/audio real-time interactive video/audio Examples: distributed

More information

Voice over IP. Demonstration 1: VoIP Protocols. Network Environment

Voice over IP. Demonstration 1: VoIP Protocols. Network Environment Voice over IP Demonstration 1: VoIP Protocols Network Environment We use two Windows workstations from the production network, both with OpenPhone application (figure 1). The OpenH.323 project has developed

More information

VoIP QoS. Version 1.0. September 4, 2006. AdvancedVoIP.com. sales@advancedvoip.com support@advancedvoip.com. Phone: +1 213 341 1431

VoIP QoS. Version 1.0. September 4, 2006. AdvancedVoIP.com. sales@advancedvoip.com support@advancedvoip.com. Phone: +1 213 341 1431 VoIP QoS Version 1.0 September 4, 2006 AdvancedVoIP.com sales@advancedvoip.com support@advancedvoip.com Phone: +1 213 341 1431 Copyright AdvancedVoIP.com, 1999-2006. All Rights Reserved. No part of this

More information

internet technologies and standards

internet technologies and standards Institute of Telecommunications Warsaw University of Technology 2015 internet technologies and standards Piotr Gajowniczek Andrzej Bąk Michał Jarociński multimedia in the Internet Voice-over-IP multimedia

More information

Per-Flow Queuing Allot's Approach to Bandwidth Management

Per-Flow Queuing Allot's Approach to Bandwidth Management White Paper Per-Flow Queuing Allot's Approach to Bandwidth Management Allot Communications, July 2006. All Rights Reserved. Table of Contents Executive Overview... 3 Understanding TCP/IP... 4 What is Bandwidth

More information

Overview of Voice Over Internet Protocol

Overview of Voice Over Internet Protocol Overview of Voice Over Internet Protocol Purva R. Rajkotia, Samsung Electronics November 4,2004 Overview of Voice Over Internet Protocol Presentation Outline History of VoIP What is VoIP? Components of

More information

Voice-Over-IP. Daniel Zappala. CS 460 Computer Networking Brigham Young University

Voice-Over-IP. Daniel Zappala. CS 460 Computer Networking Brigham Young University Voice-Over-IP Daniel Zappala CS 460 Computer Networking Brigham Young University Coping with Best-Effort Service 2/23 sample application send a 160 byte UDP packet every 20ms packet carries a voice sample

More information

SwiftBroadband and IP data connections

SwiftBroadband and IP data connections SwiftBroadband and IP data connections Version 01 30.01.08 inmarsat.com/swiftbroadband Whilst the information has been prepared by Inmarsat in good faith, and all reasonable efforts have been made to ensure

More information

6. Streaming Architectures 7. Multimedia Content Production and Management 8. Commercial Streaming Systems: An Overview 9. Web Radio and Web TV

6. Streaming Architectures 7. Multimedia Content Production and Management 8. Commercial Streaming Systems: An Overview 9. Web Radio and Web TV Outline (Preliminary) 1. Introduction and Motivation 2. Digital Rights Management 3. Cryptographic Techniques 4. Electronic Payment Systems 5. Multimedia Content Description Part I: Content-Oriented Base

More information

Computer Networks. Chapter 5 Transport Protocols

Computer Networks. Chapter 5 Transport Protocols Computer Networks Chapter 5 Transport Protocols Transport Protocol Provides end-to-end transport Hides the network details Transport protocol or service (TS) offers: Different types of services QoS Data

More information

Internet Services & Protocols Multimedia Applications, Voice over IP

Internet Services & Protocols Multimedia Applications, Voice over IP Department of Computer Science Institute for System Architecture, Chair for Computer Networks Internet Services & Protocols Multimedia Applications, Voice over IP Dipl.-Inform. Stephan Groß Room: GRU314

More information

Distributed Systems 3. Network Quality of Service (QoS)

Distributed Systems 3. Network Quality of Service (QoS) Distributed Systems 3. Network Quality of Service (QoS) Paul Krzyzanowski pxk@cs.rutgers.edu 1 What factors matter for network performance? Bandwidth (bit rate) Average number of bits per second through

More information

(Refer Slide Time: 4:45)

(Refer Slide Time: 4:45) Digital Voice and Picture Communication Prof. S. Sengupta Department of Electronics and Communication Engineering Indian Institute of Technology, Kharagpur Lecture - 38 ISDN Video Conferencing Today we

More information

Glossary of Terms and Acronyms for Videoconferencing

Glossary of Terms and Acronyms for Videoconferencing Glossary of Terms and Acronyms for Videoconferencing Compiled by Irene L. Ferro, CSA III Education Technology Services Conferencing Services Algorithm an algorithm is a specified, usually mathematical

More information

Introduction VOIP in an 802.11 Network VOIP 3

Introduction VOIP in an 802.11 Network VOIP 3 Solutions to Performance Problems in VOIP over 802.11 Wireless LAN Wei Wang, Soung C. Liew Presented By Syed Zaidi 1 Outline Introduction VOIP background Problems faced in 802.11 Low VOIP capacity in 802.11

More information

(Refer Slide Time: 01:46)

(Refer Slide Time: 01:46) Data Communication Prof. A. Pal Department of Computer Science & Engineering Indian Institute of Technology, Kharagpur Lecture - 38 Multimedia Services Hello viewers, welcome to today's lecture on multimedia

More information

Design and implementation of IPv6 multicast based High-quality Videoconference Tool (HVCT) *

Design and implementation of IPv6 multicast based High-quality Videoconference Tool (HVCT) * Design and implementation of IPv6 multicast based High-quality conference Tool (HVCT) * Taewan You, Hosik Cho, Yanghee Choi School of Computer Science & Engineering Seoul National University Seoul, Korea

More information

Module 11: TCP/IP Transport and Application Layers

Module 11: TCP/IP Transport and Application Layers Module 11: TCP/IP Transport and Application Layers 11.1 TCP/IP Transport Layer 11.1.1 Introduction to the TCP/IP transport layer The primary duties of the transport layer are to transport and regulate

More information

QOS Requirements and Service Level Agreements. LECTURE 4 Lecturer: Associate Professor A.S. Eremenko

QOS Requirements and Service Level Agreements. LECTURE 4 Lecturer: Associate Professor A.S. Eremenko QOS Requirements and Service Level Agreements LECTURE 4 Lecturer: Associate Professor A.S. Eremenko Application SLA Requirements Different applications have different SLA requirements; the impact that

More information

Native ATM Videoconferencing based on H.323

Native ATM Videoconferencing based on H.323 Native Videoconferencing based on H.323 Rodrigo Rodrigues, António Grilo, Miguel Santos and Mário S. Nunes INESC R. Alves Redol nº 9, 1 Lisboa, Portugal Abstract Due to the potential of videoconference

More information

Multimedia Networking and Network Security

Multimedia Networking and Network Security CMPT371 12-1 Multimedia Networking and Network Security 1 Multimedia Networking and Network Security This note is based on Chapters 7 and 8 of the text book. Outline of multimedia networking Multimedia

More information

Quality Estimation for Streamed VoIP Services

Quality Estimation for Streamed VoIP Services Quality Estimation for Streamed VoIP Services Mousa Al-Akhras and Hussein Zedan STRL, De Montfort University, Leicester, UK makhras@dmu.ac.uk, hzedan@dmu.ac.uk http://www.cse.dmu.ac.uk/strl/index.html

More information

TECHNICAL CHALLENGES OF VoIP BYPASS

TECHNICAL CHALLENGES OF VoIP BYPASS TECHNICAL CHALLENGES OF VoIP BYPASS Presented by Monica Cultrera VP Software Development Bitek International Inc 23 rd TELELCOMMUNICATION CONFERENCE Agenda 1. Defining VoIP What is VoIP? How to establish

More information

White paper. Latency in live network video surveillance

White paper. Latency in live network video surveillance White paper Latency in live network video surveillance Table of contents 1. Introduction 3 2. What is latency? 3 3. How do we measure latency? 3 4. What affects latency? 4 4.1 Latency in the camera 4 4.1.1

More information

WebRTC: Media Transport and Use of RTP. Colin Perkins University of Glasgow Magnus Westerlund Ericsson Jörg Ott Aalto University

WebRTC: Media Transport and Use of RTP. Colin Perkins University of Glasgow Magnus Westerlund Ericsson Jörg Ott Aalto University WebRTC: Media Transport and Use of RTP Colin Perkins University of Glasgow Magnus Westerlund Ericsson Jörg Ott Aalto University Structure Core protocols Extensions Improving transport robustness Rate control

More information

Computer Network. Interconnected collection of autonomous computers that are able to exchange information

Computer Network. Interconnected collection of autonomous computers that are able to exchange information Introduction Computer Network. Interconnected collection of autonomous computers that are able to exchange information No master/slave relationship between the computers in the network Data Communications.

More information

QoS Parameters. Quality of Service in the Internet. Traffic Shaping: Congestion Control. Keeping the QoS

QoS Parameters. Quality of Service in the Internet. Traffic Shaping: Congestion Control. Keeping the QoS Quality of Service in the Internet Problem today: IP is packet switched, therefore no guarantees on a transmission is given (throughput, transmission delay, ): the Internet transmits data Best Effort But:

More information

Transport and Network Layer

Transport and Network Layer Transport and Network Layer 1 Introduction Responsible for moving messages from end-to-end in a network Closely tied together TCP/IP: most commonly used protocol o Used in Internet o Compatible with a

More information

Multiple Choice Questions

Multiple Choice Questions Comp18112: VoIP Examples/Revision 1 Barry 7/03/11 University of Manchester School of Computer Science COMP18112: Foundations of Distributed Computing 2011 Voice over Internet Protocol (VoIP) Questions

More information

Networking Issues. Multimedia Communications: Coding, Systems, and Networking. Prof. Tsuhan Chen

Networking Issues. Multimedia Communications: Coding, Systems, and Networking. Prof. Tsuhan Chen 18-796 Multimedia Communications: Coding, Systems, and Networking Prof. Tsuhan Chen tsuhan@ece.cmu.edu Networking Issues 1 Network Characteristics Internet ATM Frame Enterprise ISDN PSTN Intranet Small

More information

Session Initiation Protocol (SIP) The Emerging System in IP Telephony

Session Initiation Protocol (SIP) The Emerging System in IP Telephony Session Initiation Protocol (SIP) The Emerging System in IP Telephony Introduction Session Initiation Protocol (SIP) is an application layer control protocol that can establish, modify and terminate multimedia

More information

Chapter 3 ATM and Multimedia Traffic

Chapter 3 ATM and Multimedia Traffic In the middle of the 1980, the telecommunications world started the design of a network technology that could act as a great unifier to support all digital services, including low-speed telephony and very

More information

Network Simulation Traffic, Paths and Impairment

Network Simulation Traffic, Paths and Impairment Network Simulation Traffic, Paths and Impairment Summary Network simulation software and hardware appliances can emulate networks and network hardware. Wide Area Network (WAN) emulation, by simulating

More information

Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc

Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc (International Journal of Computer Science & Management Studies) Vol. 17, Issue 01 Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc Dr. Khalid Hamid Bilal Khartoum, Sudan dr.khalidbilal@hotmail.com

More information

IP - The Internet Protocol

IP - The Internet Protocol Orientation IP - The Internet Protocol IP (Internet Protocol) is a Network Layer Protocol. IP s current version is Version 4 (IPv4). It is specified in RFC 891. TCP UDP Transport Layer ICMP IP IGMP Network

More information

EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics and Computer Science

EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics and Computer Science EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics and Computer Science Examination Computer Networks (2IC15) on Monday, June 22 nd 2009, 9.00h-12.00h. First read the entire examination. There

More information

CHAPTER. The Technology of Internet Protocol Networks

CHAPTER. The Technology of Internet Protocol Networks IPTV 03 11/2/06 8:54 AM Page 69 CHAPTER 3 The Technology of Internet Protocol Networks IPTV 03 11/2/06 8:54 AM Page 70 70 Chapter 3 As the title of this book implies, IPTV s foundation is the Internet

More information

Evaluating Data Networks for Voice Readiness

Evaluating Data Networks for Voice Readiness Evaluating Data Networks for Voice Readiness by John Q. Walker and Jeff Hicks NetIQ Corporation Contents Introduction... 2 Determining Readiness... 2 Follow-on Steps... 7 Summary... 7 Our focus is on organizations

More information

Multimedia Networking. Real-Time (Phone) Over IP s Best-Effort. Recovery From Jitter. Settings. up to 10 % loss is tolerable TCP instead of UDP?

Multimedia Networking. Real-Time (Phone) Over IP s Best-Effort. Recovery From Jitter. Settings. up to 10 % loss is tolerable TCP instead of UDP? Multimedia Networking Principles Classify multimedia applications Identify the network services the apps need Making the best of best effort service Mechanisms for providing QoS Protocols and Architectures

More information

Combining Voice over IP with Policy-Based Quality of Service

Combining Voice over IP with Policy-Based Quality of Service TechBrief Extreme Networks Introduction Combining Voice over IP with Policy-Based Quality of Service Businesses have traditionally maintained separate voice and data networks. A key reason for this is

More information

CHAPTER 4 Multimedia over IP

CHAPTER 4 Multimedia over IP CHAPTER 4 Multimedia over IP The idea of multimedia communications is very appealing text, graphics, sound, and video all combined to enrich the ways in which we communicate and to transform communications

More information

Internet Security. Internet Security Voice over IP. Introduction. ETSF10 Internet Protocols 2011-11-22. ETSF10 Internet Protocols 2011

Internet Security. Internet Security Voice over IP. Introduction. ETSF10 Internet Protocols 2011-11-22. ETSF10 Internet Protocols 2011 Internet Security Voice over IP ETSF10 Internet Protocols 2011 Kaan Bür & Jens Andersson Department of Electrical and Information Technology Internet Security IPSec 32.1 SSL/TLS 32.2 Firewalls 32.4 + Voice

More information

Quality of Service in the Internet. QoS Parameters. Keeping the QoS. Traffic Shaping: Leaky Bucket Algorithm

Quality of Service in the Internet. QoS Parameters. Keeping the QoS. Traffic Shaping: Leaky Bucket Algorithm Quality of Service in the Internet Problem today: IP is packet switched, therefore no guarantees on a transmission is given (throughput, transmission delay, ): the Internet transmits data Best Effort But:

More information

- TCP and UDP - Transport Layer Protocols

- TCP and UDP - Transport Layer Protocols 1 Transport Layer Protocols - TCP and UDP - The Transport layer (OSI Layer-4) does not actually transport data, despite its name. Instead, this layer is responsible for the reliable transfer of data, by

More information

Measurement of IP Transport Parameters for IP Telephony

Measurement of IP Transport Parameters for IP Telephony Measurement of IP Transport Parameters for IP Telephony B.V.Ghita, S.M.Furnell, B.M.Lines, E.C.Ifeachor Centre for Communications, Networks and Information Systems, Department of Communication and Electronic

More information

Multimedia Applications. Streaming Stored Multimedia. Classification of Applications

Multimedia Applications. Streaming Stored Multimedia. Classification of Applications Chapter 2: Basics Chapter 3: Multimedia Systems Communication Aspects and Services Multimedia Applications and Communication Multimedia Transfer and Protocols Quality of Service and Resource Management

More information

Voice over IP. Overview. What is VoIP and how it works. Reduction of voice quality. Quality of Service for VoIP

Voice over IP. Overview. What is VoIP and how it works. Reduction of voice quality. Quality of Service for VoIP Voice over IP Andreas Mettis University of Cyprus November 23, 2004 Overview What is VoIP and how it works. Reduction of voice quality. Quality of Service for VoIP 1 VoIP VoIP (voice over IP - that is,

More information

Performance Evaluation of VoIP Services using Different CODECs over a UMTS Network

Performance Evaluation of VoIP Services using Different CODECs over a UMTS Network Performance Evaluation of VoIP Services using Different CODECs over a UMTS Network Jianguo Cao School of Electrical and Computer Engineering RMIT University Melbourne, VIC 3000 Australia Email: j.cao@student.rmit.edu.au

More information

Ethernet. Ethernet. Network Devices

Ethernet. Ethernet. Network Devices Ethernet Babak Kia Adjunct Professor Boston University College of Engineering ENG SC757 - Advanced Microprocessor Design Ethernet Ethernet is a term used to refer to a diverse set of frame based networking

More information

Basic principles of Voice over IP

Basic principles of Voice over IP Basic principles of Voice over IP Dr. Peter Počta {pocta@fel.uniza.sk} Department of Telecommunications and Multimedia Faculty of Electrical Engineering University of Žilina, Slovakia Outline VoIP Transmission

More information

VIDEOCONFERENCING. Video class

VIDEOCONFERENCING. Video class VIDEOCONFERENCING Video class Introduction What is videoconferencing? Real time voice and video communications among multiple participants The past Channelized, Expensive H.320 suite and earlier schemes

More information

Video Streaming Protocols

Video Streaming Protocols Digital Video Encoding The Helios HD/SD cameras support four encoding modes providing up to two independent streams of digitally encoded video as listed below: H.264 Only MJPEG Only H.264 Stream 1 and

More information

Final for ECE374 05/06/13 Solution!!

Final for ECE374 05/06/13 Solution!! 1 Final for ECE374 05/06/13 Solution!! Instructions: Put your name and student number on each sheet of paper! The exam is closed book. You have 90 minutes to complete the exam. Be a smart exam taker -

More information

This topic lists the key mechanisms use to implement QoS in an IP network.

This topic lists the key mechanisms use to implement QoS in an IP network. IP QoS Mechanisms QoS Mechanisms This topic lists the key mechanisms use to implement QoS in an IP network. QoS Mechanisms Classification: Each class-oriented QoS mechanism has to support some type of

More information

Module 7 Internet And Internet Protocol Suite

Module 7 Internet And Internet Protocol Suite Module 7 Internet And Internet Protocol Suite Lesson 21 Internet and IPv4 LESSON OBJECTIVE General The lesson will discuss a popular network layer protocol, i.e. the Internet Protocol Specific The focus

More information

Clearing the Way for VoIP

Clearing the Way for VoIP Gen2 Ventures White Paper Clearing the Way for VoIP An Alternative to Expensive WAN Upgrades Executive Overview Enterprises have traditionally maintained separate networks for their voice and data traffic.

More information

The Fax on IP Networks. White Paper February 2011

The Fax on IP Networks. White Paper February 2011 The Fax on IP Networks White Paper February 2011 2 The Fax on IP Networks Contents Overview... 3 Group 3 Fax Technology... 4 G.711 Fax Pass-Through... 5 T.38 IP Fax Relay... 6 Network Design Considerations...

More information

Network Security Systems Fundamentals for ITS Professionals

Network Security Systems Fundamentals for ITS Professionals Network Security Systems Fundamentals for ITS Professionals Chris Adesanya Sr. Systems Engineer Panasonic System Solutions Company adesanyac@us.panasonic.com BICSI Southeast Regional Meeting Dulles, VA

More information

12 Quality of Service (QoS)

12 Quality of Service (QoS) Burapha University ก Department of Computer Science 12 Quality of Service (QoS) Quality of Service Best Effort, Integrated Service, Differentiated Service Factors that affect the QoS Ver. 0.1 :, prajaks@buu.ac.th

More information

920-803 - technology standards and protocol for ip telephony solutions

920-803 - technology standards and protocol for ip telephony solutions 920-803 - technology standards and protocol for ip telephony solutions 1. Which CODEC delivers the greatest compression? A. B. 711 C. D. 723.1 E. F. 726 G. H. 729 I. J. 729A Answer: C 2. To achieve the

More information

Introduce Quality of Service in your IP_to_IP W@N unreliable infrastructure

Introduce Quality of Service in your IP_to_IP W@N unreliable infrastructure Introduce Quality of Service in your IP_to_IP W@N unreliable infrastructure QV QoS Proxy server The QV-PROXY supplies two features : introduction of Error Correction mechanism improving the QoS and delivery

More information

Applications that Benefit from IPv6

Applications that Benefit from IPv6 Applications that Benefit from IPv6 Lawrence E. Hughes Chairman and CTO InfoWeapons, Inc. Relevant Characteristics of IPv6 Larger address space, flat address space restored Integrated support for Multicast,

More information

Multimedia Requirements. Multimedia and Networks. Quality of Service

Multimedia Requirements. Multimedia and Networks. Quality of Service Multimedia Requirements Chapter 2: Representation of Multimedia Data Chapter 3: Multimedia Systems Communication Aspects and Services Multimedia Applications and Transfer/Control Protocols Quality of Service

More information

USING DIGITAL SIGNAL PROCESSOR IN VOICE OVER IP COMMUNICATION

USING DIGITAL SIGNAL PROCESSOR IN VOICE OVER IP COMMUNICATION USING DIGITAL SIGNAL PROCESSOR IN VOICE OVER IP COMMUNICATION Marek Huczala Department of Telecommunications, Brno University of Technology, Purkynova 118, 612 00 Brno, Czech Republic, e-mail: huczala@kn.vutbr.cz

More information

IAB CONCERNS ABOUT CONGESTION CONTROL. Iffat Hasnian 1832659

IAB CONCERNS ABOUT CONGESTION CONTROL. Iffat Hasnian 1832659 IAB CONCERNS ABOUT CONGESTION CONTROL Iffat Hasnian 1832659 IAB CONCERNS Outline 1- Introduction 2- Persistent High Drop rate Problem 3- Current Efforts in the IETF 3.1 RTP 3.2 TFRC 3.3 DCCP 3.4 Audio

More information

ESSENTIALS. Understanding Ethernet Switches and Routers. April 2011 VOLUME 3 ISSUE 1 A TECHNICAL SUPPLEMENT TO CONTROL NETWORK

ESSENTIALS. Understanding Ethernet Switches and Routers. April 2011 VOLUME 3 ISSUE 1 A TECHNICAL SUPPLEMENT TO CONTROL NETWORK VOLUME 3 ISSUE 1 A TECHNICAL SUPPLEMENT TO CONTROL NETWORK Contemporary Control Systems, Inc. Understanding Ethernet Switches and Routers This extended article was based on a two-part article that was

More information