AdvMultiMedia2k7 01H

11/2/2011
Advanced Multimedia Technology

Roadmap
Introduction Chapter 1: Multimedia Network
RTP & RTCP QoS for multimedia network
Chapter 2: Voice and Video Over IP

SIP protocol VoIP VideoIP
Chapter 3: MPEG-4 & H264
11/2/2011
Nguyen Chan Hung Hanoi University of Technology
Introduction
Targets:
State-of-the-art knowledge on multimedia technology & applications Information on real-world multimedia systems How-to tutorials / Hand-ons excersices / Technological Demonstrations which inspire innovations Some smart students can setup practical systems for themselves
Show examples:
VoIP using ADSL VoWiFi Mobile Nokia, PDA Video Streaming TV programs Internet Radio broadcast station Remote Home monitor RDLAB Project (See next slide)
Pre-requirements:
Multimedia Computer network
11/2/2011
11/2/2011
Introduction (2)
More information:
The Internet (anything you need) http://Rdlab410.dyndns.org/rdlab/ Introduction to Reseach and Development Laboratory of Multimedia Technology (C9 Room410 FET HUT) http://Rdlab410.dyndns.org/4SV/ Document for students
11/2/2011
Chapter 1: Multimedia networks
Overview:
Challenges of Multimedia networks & applications RTP (Real Time Protocol) & RTCP QoS mechanisms
Traffic Scheduling & Policing: Int-serv, Diff-serv
11/2/2011
11/2/2011
Multimedia requirements App classes

Typically sensitive to delay, but can tolerate packet loss (would cause minor glitches that can be concealed) Data contains audio and video content (continuous media), three classes of applications: Streaming stored contents Unidirectional Real-Time Interactive Real-Time
11/2/2011 Nguyen Chan Hung Hanoi University of Technology 5
Application Classes
Streaming stored contents Clients request audio/video files from servers and pipeline reception over the network and display Interactive: user can control operation (similar to VCR: pause, resume, fast forward, rewind, etc.) Delay: from client request until display start can be 1 to 10 seconds
Unidirectional Real-Time: Similar to existing TV and radio stations, but delivery over the Internet Non-interactive, just listen/view Interactive Real-Time : Phone or video conference More stringent delay requirement than Streaming & Unidirectional because of real-time nature Video: < 150 msec acceptable Audio: < 150 msec good, <400 msec acceptable
11/2/2011
11/2/2011
Challenges
TCP/UDP/IP suite provides best-effort, no guarantees on expectation or variance of packet delay Streaming applications delay of 5 to 10 seconds is typical and has been acceptable, but performance deteriorate if links are congested (transoceanic) Real-Time Interactive requirements on delay and its jitter have been satisfied by over-provisioning (providing plenty of bandwidth), what will happen when the load increases?... Most router implementations use only First-ComeFirst-Serve (FCFS) packet processing and transmission scheduling
Making the best of best effort Internet

To mitigate impact of besteffort Internet, we can: Use UDP to avoid TCP and its slow-start phase Buffer content at client and control playback to remedy jitter We can timestamp packets, so that receiver knows when the packets should be played back. Adapt compression level to available bandwidth
11/2/2011
We can send redundant packets to mitigate the effects of packet loss. We will discuss all these solutions.
11/2/2011
Internet evolution to better support multimedia

Integrated services philosophy: Change Internet protocols so that applications can reserve end-to-end bandwidth
Need to deploy protocol that reserves bandwidth Must modify scheduling policies in routers to honor reservations Application must provide the network with a description of its traffic, and must further abide to this description.
Requires new, complex software in hosts & routers
Differentiated services philosophy: Fewer changes to Internet infrastructure, yet provide 1st and 2nd class service. Datagrams are marked. User pays more to send/receive 1st class packets. ISPs pay more to backbones to send/receive 1st class packets.
11/2/2011
Internet evolution to better support multimedia (2)

Laissez-faire philosophy No reservations, no datagram marking As demand increases, provision more bandwidth Place stored content at edge of network:
ISPs & backbones add caches Content providers put content in CDN nodes P2P: choose nearby peer with content
Virtual private networks (VPNs) Reserve permanent blocks of bandwidth for enterprises. Routers distinguish VPN traffic using IP addresses Routers use special scheduling policies to provide reserved bandwidth.
11/2/2011
10
11/2/2011
RTP & RTCP
11/2/2011
11
Real-Time Protocol (RTP)

RTP specifies a packet structure for packets carrying audio and video data: RFC 1889. RTP packet provides
payload type identification packet sequence numbering timestamping
RTP runs in the end systems. RTP packets are encapsulated in UDP segments or optionally in TCP Interoperability: If two Internet phone applications run RTP, then they may be able to work together
12
11/2/2011
11/2/2011
Fundamental Design Philosophies of RTP
To build a mechanism for robust, real-time media delivery above an unreliable transport layer. RTP design follows 2 philosophies:
application-level framing end-to-end principle.
11/2/2011
13
Application-Level Framing
Only the application has sufficient knowledge of its data to make an informed decision about how that data should be transported. Transport protocol should expose the details of their delivery as much as possible the application can make an appropriate response if an error occurs.
RTP Differ from TCP design !!
The application cooperating with the transport to achieve reliable delivery. Real-time audio and visual media is:
loss tolerant BUT has strict timing bounds.
By using application-level framing with UDP-based transport, multimedia applications can:

Be able to accept losses where necessary, Havethe flexibility to use the full spectrum of recovery techniques, such as retransmission and forward error correction, where appropriate.
11/2/2011
14
11/2/2011
The End-to-End Principle

To design a system that must communicate reliably across a network. Similar to TCP principle Implies that intelligence is at the endpoints, not within the network. Case studies:
Internet: Smart endpoints dumb network Telephony: Smart network dumb endpoints (OR terminal) MPEG: Smart sender dumb receiver
11/2/2011 15
The RTP Specifications

RTP was published as an IETF proposed standard (RFC 1889) in January 1996, The first revision of ITU recommendation H.323 included a verbatim copy of the RTP specification; later revisions reference the current IETF standard. Two parts of RTP:
the data transfer protocol an associated control protocol (RTCP)
11/2/2011
16
11/2/2011
RTP and OSI model

RTP mostly performs tasks typically of transport-layer protocol RTP libraries provide a transport-layer interface that extend UDP:
port numbers, IP addresses error checking across segment payload type identification packet sequence numbering time-stamping
RTP performs some tasks of the session layer (i.e. spanning disparate transport connections and managing participant identification in a transport-neutral manner) RTP also performs some tasks of Presentation layer (i.e. defining standard representations for media data).
11/2/2011
17
RTP and related standards
11/2/2011
18
11/2/2011
RTP Sessions
Definition: A RTP session consists of a group of participants who are communicating using RTP. A participant may be active in multiple RTP sessions
e.g. one session for exchanging audio data and another session for exchanging video data.
For each participant, the session is identified by a network address and port pair to which data should be sent, and a port pair on which data is received. The send and receive ports may be the same. Each port pair comprises two adjacent ports:
an even-numbered port for RTP data packets, the next higher (odd-numbered) port for RTCP control packets.
The default port pair is 5004 and 5005 for UDP/IP, but many applications dynamically allocate ports during session setup and ignore the default. RTP sessions are designed to transport a single type of media; each media type should be carried in a separate RTP session.
11/2/2011
19
Types of RTP Sessions
11/2/2011
20
10
11/2/2011
RTP Example
Consider sending 64 kbps PCM-encoded voice over RTP. Application collects the encoded data in chunks, e.g., every 20 msec = 160 bytes in a chunk. (= 8000 bytes/sec/50) The audio chunk along with the RTP header form the RTP packet, which is encapsulated into a UDP segment. RTP header indicates type of audio encoding in each packet;
senders can change encoding during a conference.
RTP header also contains sequence numbers and timestamps.
11/2/2011
21
RTP Implementations
RTP Sender:
Uncompressed media dataaudio or video is captured into a buffer, from which compressed frames are produced. Frames may be encoded in several ways depending on the compression algorithm used (e.g. H264, MPEG-4) Compressed frames are loaded into RTP packets for sending.
If frames are large, they may be fragmented into several RTP packets; if frames are small, several frames may be bundled into a single RTP packet. A channel coder may be used to generate error correction packets or to reorder packets before transmission.
After sending the RTP packets, the buffered media of those packets is freed. The sender must buffer data for some time after the corresponding packets have been sent, depending on the codec and error correction scheme used. The sender is responsible for generating periodic status reports for the media streams it is generating, e.g. lip synchronization. It also receives reception quality feedback from other participants and may use that information to adapt its transmission.
11
11/2/2011
RTP Implementations (2)
RTP receiver Receiver is responsible for:

Collecting RTP packets from the network, Correcting any losses, Recovering the timing, Decompressing the media, Presenting the result to the user. Sends reception quality feedback, allowing the sender to adapt the transmission to the receiver, Maintains a database of participants in the session.
RTP and QoS

RTP does NOT provide any mechanism to ensure timely delivery of data or provide other quality of service guarantees. RTP encapsulation is only seen at the end systems -- it is NOT seen by intermediate routers.
Router Do not make any special effort to ensure that RTP packets arrive at the destination in a timely matter. In order to provide QoS to an application, the Internet must provide a mechanism, such as RSVP, for the application to reserve network resources.
24
11/2/2011
12
11/2/2011
RTP Streams
RTP allows each source (for example, a camera or a microphone) to be assigned its own independent RTP stream of packets.
For example, for a videoconference between two participants, four RTP streams could be opened:
2 streams for transmitting the audio (one in each direction) 2 streams for the video (one in each direction).
Some popular encoding techniques (e.g. MPEG1 and MPEG2) bundle the audio and video into a single stream during the encoding process. only one RTP stream is generated in each direction. For a many-to-many multicast session, all of the senders and sources typically send their RTP streams into the same multicast tree with the same multicast address.
11/2/2011
25
Translators
Definition: A translator is an intermediate system that operates on RTP data while maintaining the synchronization source and timeline of a stream. For examples: Systems that
Convert between media-encoding formats without mixing, Bridge between different transport protocols, Add or remove encryption, Filter media streams.
A translator is invisible to the RTP end systems There are a few classes of translators:
Bridges are one-to-one translators that don't change the media encoding
e.g, gateways between different transport protocols, like RTP/UDP/IP and RTP/ATM, or RTP/UDP/IPv4 and RTP/UDP/IPv6. Bridges is the simplest class of translator Cause no changes to the RTP or RTCP data.
11/2/2011
26
13
11/2/2011
Translator (2)
Transcoders are one-to-one translators that change the media encoding
E.g, decoding the compressed data and reencoding it with a different payload format to better suit the characteristics of the output network. The payload type usually changes, as may the padding, but other RTP header fields generally remain unchanged.
Exploders are one-to-many translators, which take in a single packet and produce multiple packets. Mergers are many-to-one translators, combining multiple packets into one. This is the inverse of the previous category.
11/2/2011
27
Mixers
Definition: A mixer is an intermediate system that receives RTP packets from a group of sources and combines them into a single output, possibly changing the encoding, before forwarding the result.
Examples include the networked equivalent of an audio mixing deck, or a video picture-in-picture (PIP) device.
Because the timing of the input streams generally will not be synchronized, the mixer will have to make its own adjustments to synchronize the media before combining them, and hence it becomes the synchronization source of the output media stream. A mixer may use playout buffers for each arriving media stream to help maintain the timing relationships between streams. A mixer has its own SSRC, which is inserted into the data packets it generates. The SSRC identifiers from the input data packets are copied into the CSRC list of the output packet.
11/2/2011
28
14
11/2/2011
Mixers (2)
A mixer has a unique view of the session: It sees all sources as synchronization sources, whereas the other participants see some synchronization sources and some contributing sources. In above figure, participant X receives data from three synchronization sources Y, Z, and Mwith A and B contributing sources in the mixed packets coming from M. Participant A sees B and M as synchronization sources with X, Y, and Z contributing to M. The mixer generates RTCP sender and receiver reports separately for each half of the session, and it does not forward them between the two halves. It forwards RTCP source description and BYE packets so that all participants can be identified
RTP packet format
11/2/2011
30
15
11/2/2011
RTP packet format (2)

Payload Type (7 bits): Used to indicate the type of encoding that is currently being used. If a sender changes the encoding in the middle of a conference, the sender informs the receiver through this payload type field. Payload type 0: PCM mu-law, 64 Kbps Payload type 3, GSM, 13 Kbps Payload type 7, LPC, 2.4 Kbps Payload type 26, Motion JPEG Payload type 31. H.261 Payload type 33, MPEG2 video Sequence Number (16 bits): The sequence number increments by one for each RTP packet sent; may be used to detect packet loss and to restore packet sequence.
11/2/2011
31

Timestamp field (32 bytes long). Reflects the sampling instant of the first byte in the RTP data packet. The receiver can use the timestamps to remove packet jitter and provide synchronous playout. The timestamp is derived from a sampling clock at the sender.
Example: for audio the timestamp clock increments by one for each sampling period (for example, each 125 usecs for a 8 KHz sampling clock); if the audio application generates chunks consisiting of 160 encoded samples, then the timestamp increases by 160 for each RTP packet when the source is active. The timestamp clock continues to increase at a constant rate even the source is inactive.
SSRC field (32 bits long). Identifies the source of the RTP stream. stream in a RTP session should have a distinct SSRC.
Each
Definition: The synchronization source (SSRC) identifies participants within an RTP session. It is a per-session identifier that is mapped to a long-lived canonical name, CNAME (e.g. user@host.domain), through the RTP control protocol
Be chosen randomly to minimize collision probability RTP Partcipants must resolve possible conflict of SSRC collision. (sent BYE and choose another SSRC)
11/2/2011
32
16
11/2/2011

Contributing sources (CSRCs)
Under normal circumstances, RTP data is generated by a single source, But When multiple RTP streams pass through a mixer or translator, multiple data sources may have contributed to an RTP data packet. The list of contributing sources (CSRCs) identifies participants who have contributed to an RTP packet but were not responsible for its timing and synchronization. Each contributing source identifier is a 32-bit integer, corresponding to the SSRC of the participant who contributed to this packet. The length of the CSRC list is indicated by the CC field in the RTP header.
Payload Headers
The mandatory RTP header provides information that is common to all payload formats. Sometime, a payload format will need more information for optimal operation;
This information forms an additional header that is defined as part of the payload format specification.
The payload header is included in an RTP packet following the fixed header and any CSRC list and header extension. The definition of the payload header constitutes the majority of a payload format specification.
Example: palyload header for H.261 video is defined in RFC 2032 and RFC 2736
Real-Time Control Protocol (RTCP)

Works in conjunction with RTP. Each participant in an RTP session periodically transmits RTCP control packets to all other participants.
Each RTCP packet contains sender and/or receiver reports that report statistics useful to the application.
Statistics include:
number of packets sent, number of packets lost, interarrival jitter, etc.
This feedback to the application can be used to control performance and for diagnostic purposes.
The sender may modify its transmissions based on the feedback.
11/2/2011
34
17
11/2/2011
RTCP (2)
For an RTP session there is typically a single multicast address; all RTP and RTCP packets belonging to the session use the multicast address. RTP and RTCP packets are distinguished from each other through the use of distinct port numbers. To limit traffic, each participant reduces his RTCP traffic as the number of conference participants increases.
11/2/2011
35
RTCP packet format

Five types of RTCP packets are defined in the RTP specification: receiver report (RR), sender report (SR), source description (SDES), membership management (BYE), and application-defined (APP). They all follow a common structure: (see figure)
11/2/2011
36
18
11/2/2011
RTCP packet format (2)

Version number (V). The version number is always 2 for the current version of RTP. Padding (P). The padding bit indicates that the packet has been padded out beyond its natural size. If this bit is set, one or more octets of padding have been added to the end of this packet, and the last octet contains a count of the number of padding octets added. Item count (IC). Some packet types contain a list of items, perhaps in addition to some fixed, type-specific information.
The item count field is used by these packet types to indicate the number of items included in the packet (the field has different names in different packet types depending on its use). Up to 31 items may be included in each RTCP packet, limited also by the maximum transmission unit of the network. If more than 31 items are needed, the application must generate multiple RTCP packets.
Packet type (PT). The packet type identifies the type of information carried in the packet. Five standard packet types are defined in the RTP specification; other types may be defined in the future Length. The length field denotes the length of the packet contents following the common header.
It is measured in units of 32-bit words because all RTCP packets are multiples of 32 bits in length
RTCP Packets - Overview

Receiver report packets: (RR) Fraction of packets lost, Last sequence number, Average interarrival jitter. Sender report packets: (SR) SSRC of the RTP stream, The current time, The number of packets sent, The number of bytes sent. Source description packets (SDES) e-mail address of the sender, The sender's name, The SSRC of the associated RTP stream. Packets provide a mapping between the SSRC and the user/host name. BYE: Membership Control A BYE packet is generated when a participant leaves the session, or when it changes its SSRC for example, because of a collision. APP: Application-Defined RTCP Packets The final class of RTCP packet (APP) allows for applicationdefined extensions.
11/2/2011
38
19
11/2/2011
Receiver Report
The reception quality feedback in RR packets is useful not only for the sender, but also for other participants and third-party monitoring tools.
The RR feedback allow the sender to adapt its transmissions according to the feedback. Other participants can determine whether problems are local or common to several receivers, Network managers may use monitors that receive only the RTCP packets to evaluate the performance of their networks.
11/2/2011
39
Sender report
From the SR, an application can calculate the average payload data rate and the average packet rate over an interval without receiving the data. The ratio of the two is the average payload size. If it can be assumed that packet loss is independent of packet size, then:
Receiver Throughput = number of packets * average payload size
The timestamps are used to generate a correspondence between media clocks and the NTP Used for lip-synch
11/2/2011
40
20
11/2/2011
SDES
Source DEScription (SDES) provides participant identification and supplementary details, such as location, e-mail address, and telephone number. The information in SDES packets is typically entered by the user and is often displayed in the graphical user interface of an application Each list of SDES items starts with the SSRC of the source being described, followed by one or more entries with the format shown in Figure. Each entry starts with a type and a length field, then the item text itself in UTF-8 format. The length field indicates how many octets of text are present; the text is not null-terminated.
11/2/2011
41
BYE
The RC field in the common RTCP header indicates the number of SSRC identifiers in the packet. On receiving a BYE packet, an implementation should assume that the listed sources have left the session and ignore any further RTP and RTCP packets from that source. A BYE packet may also contain text indicating the reason for leaving a session, suitable for display in the user interface.
21
11/2/2011
RTCP APP: Application-Defined RTCP Packets

The application-defined packet name is a four-character prefix intended to uniquely identify this extension, with each character being chosen from the ASCII character set. Application-defined packets are used for nonstandard extensions to RTCP, and for experimentation with new features. Experimenters use APP to try new features, and then register new packet types if the features have wider use. Several applications generate APP packets, implementations should be prepared to ignore unrecognized APP packets.
11/2/2011
43
Synchronization of Streams
RTCP can be used to synchronize different media streams within a RTP session. Consider a videoconferencing application for which each sender generates one RTP stream for video and one for audio. The timestamps in these RTP packets are tied to the video and audio sampling clocks, and are NOT tied to the wallclock time (i.e., to real time). Each RTCP sender-report packet contains, for the most recently generated packet in the associated RTP stream:
the timestamp of the RTP packet the wall-clock time for when the packet was created. Thus the RTCP senderreport packets associate the sampling clock to the realtime clock.
Receivers can use this association to synchronize the playout of audio and video.
11/2/2011
44
22
11/2/2011
RTCP Bandwidth Scaling

RTCP attempts to limit its traffic to 5% of the session bandwidth.
For example, one sender, sending video at 2 Mbps. RTCP limit its traffic to 100 Kbps.
75% of this rate, or 75 kbps, to the receivers; The remaining 25% of the rate, or 25 kbps, to the sender.
The 75 kbps devoted to the receivers is equally shared among the receivers.
if there are R receivers, then each receiver gets to send RTCP traffic at a rate of 75/R kbps and the sender gets to send RTCP traffic at a rate of 25 kbps.
A participant (a sender or receiver) determines the RTCP packet transmission period by dynamically calculating the average RTCP packet size (across the entire session) and dividing the average RTCP packet size by its allocated rate.
11/2/2011
45
Audio Capture, Digitization, and Framing

Audio capture devices can produce samples with 8-, 16-, or 24-bit resolution, Linear, -law or A-law quantization, Rates between 8,000 and 96,000 samples per second, mono or stereo. It may be necessary to convert the media to an alternative format before the media can be used
for example, changing the sample rate or converting from linear to -law quantization
Many speech codecs perform voice activity detection with silence suppression
11/2/2011
46
23
11/2/2011
Video Capture
Most Video codec use inter-frame compression introduce delay YUV to RGB conversion
Use of Prerecorded Content

RTP makes no distinction between live and prerecorded media, and senders generate data packets from compressed frames in the same way First, the sender must generate a new SSRC and choose random initial values for the RTP timestamp and sequence number. During the streaming process, the sender must be prepared to handle SSRC collisions and should generate and respond to RTCP packets for the stream. Also, if the sender implements a control protocol, such as RTSP, that allows the receiver to pause or seek within the media stream, the sender must keep track of such interactions so that it can insert the correct sequence number and timestamp into RTP data packets
24
11/2/2011
Fragmentation of a Media Frame into RTP Packets
The fragmentation process is critical to the quality of the media in the presence of packet loss. The ability to decode each fragment independently is desirable
otherwise loss of a single fragment will result in the entire frame being discarded
When multiple RTP packets are generated for each frame, the sender must choose between sending the packets in a single burst and spreading their transmission across the framing interval.
Sending the packets in a single burst reduces the end-to-end delay but may overwhelm the limited buffering capacity of the network or receiving host. it is recommended that the sender spread the packets out in time across the framing interval.
11/2/2011
49
Packet Reception Input queues

Separation between the packet reception and playout routines by input queues (See figure) It is important to store the exact arrival time, M, of RTP data packets to calculate interarrival jitter The arrival time should be measured according to a local reference wall clock, T, converted to the media clock rate, R. Since the receiver do not have such a clock, so usually we calculate the arrival time by sampling the reference clock (typically the system wall clock time) and converting it to the local timeline: where the offset is used to map from the reference clock to the media timeline, in the process correcting for skew between the media clock and the reference clock.
11/2/2011
50
25
11/2/2011
Disruption of Interpacket Timing during Network Transit

There are bursts when several packets arrive at once Gaps when no packets arrive Packets may even arrive out of order. The receiver does not know when data packets are going to arrive, so it should be prepared to accept packets in bursts, and in any order
11/2/2011
51
The Playout Buffer
Data packets are extracted from their input queue and inserted into a sourcespecific playout buffer sorted by their RTP timestamps. Frames are held in the playout buffer for a period of time to smooth timing variations caused by the network. Holding the data in a playout buffer also allows the pieces of fragmented frames to be received and grouped, and it allows any error correction data to arrive. The frames are then decompressed, any remaining errors are concealed, and the media is rendered for the user. A single buffer may be used to compensate for network timing variability and as a decode buffer for the media codec.
11/2/2011
It is also possible to separate these functions: using separate buffers for jitter removal and decoding.
Nguyen Chan Hung Hanoi University of Technology 52
26
11/2/2011
The Playout Buffer Data Structures

The playout buffer comprises a time-ordered linked list of nodes. Each node represents a frame of media data, with associated timing information. The data structure for each node contains pointers to:
the adjacent nodes, the arrival time, RTP timestamp, desired playout time for the frame, and pointers to both The compressed fragments of the frame (the data received in RTP packets) and The uncompressed media data
The Playout Buffer Data Structures (2)

When the first RTP packet in a frame arrives, it is removed from the input queue and positioned in the playout buffer in order of its RTP timestamp. This involves creating a new playout buffer node, which is inserted into the linked list of the playout buffer. The compressed data from the recently arrived packet is linked from the playout buffer node, for later decoding. The frame's playout time is then calculated The newly created node resides in the playout buffer until its playout time is reached.
During this waiting period, packets containing other fragments of the frame may arrive and are linked from the node.
Once all the fragments of a frame have been received, the decoder is invoked and the resulting uncompressed frame linked from the playout buffer node. Determining that a complete frame has been received depends on the codec:
Audio codecs typically do not fragment frames, and they have a single packet per frame (MPEG Audio Layer-3MP3is a common exception); Video codecs often generate multiple packets per video frame, with the RTP marker bit being set to indicate the RTP packet containing the last fragment.
27
11/2/2011
Playout buffer processing

The decision of when to invoke the decoder depends on the receiver and is not specified by RTP.
Frames can be decoded as soon as they arrive or kept compressed until the last possible moment.
The choice depends on the relative availability of processing cycles and storage space for uncompressed frames, and perhaps on the receiver's estimate of future resource availability.
For example, a receiver may wish to decode data early if it knows that an index frame is due and it will shortly be busy.
When the playout time for a frame arrives, it is queued for playout.
The receiver must make its best effort to decode the frame, even if some fragments are missing, because this is the last chance before the frame is needed. Error concealment may be invoked to hide any uncorrected packet loss.
Once the frame has been played out, the corresponding playout buffer node and its linked data should be destroyed or recycled. If error concealment is used, it may be desirable to delay this process until the surrounding frames have also been played out because the linked media data may be useful for the concealment operation. RTP packets arriving late and corresponding to frames that have missed their playout point should be discarded.
The timeliness of a packet can be determined by comparison of its RTP timestamp with the timestamp of the oldest packet in the playout buffer
Clock skew
Calculation of clock skew:

observe the rate of the sender clockthe RTP timestampand compare with the local clock. If TR(n) is the RTP timestamp of the n th packet received, and TL(n) is the value of the local clock at that time, then the clock skew can be estimated as follows:
11/2/2011
56
28
11/2/2011
The Playout calculation
5 steps:
1.
2.
3.
4.
The sender timeline is mapped to the local playout timeline, compensating for the relative offset between sender and receiver clocks, to derive a base time for the playout calculation If necessary, the receiver compensates for clock skew relative to the sender, by adding a skew compensation offset that is periodically adjusted to the base time The playout delay on the local timeline is calculated according to a senderrelated component of the playout delay and a jitter-related component The playout delay is adjusted
if the route has changed , if packets have been reordered, if the chosen playout delay causes frames to overlap, in response to other changes in the media
5.
Finally, the playout delay is added to the base time to derive the actual playout time for the frame.
Nguyen Chan Hung Hanoi University of Technology 57
11/2/2011
Review questions
1. 2.
3.
4. 5.
6. 7. 8.
9.
Compare RTP and TCP What are their main differences & similarities ? What is a RTP stream ? Find out an example of RTP stream in realworld applications. What is a RTP session ? Find out an example of RTP session in realworld applications. Define SSRC/CSRC ? Describe their roles in RTP. What will happen if in a video conferencing session, a host find out that it use the same SSRC as one of other participants ? Find some examples of RTP mixer/translator in real-world applications. How often does RTP end-point send audio package ? Why ? What are the purposes of using sequence number / time stamp in RTP header ? A RTP session and a FTP session sharing a congested ADSL link.
Will the RTP session affected ? Describe the interaction between PC applications, ADSL modem and ISP router. Which traffic will be prioritized? Why ? How ?
11/2/2011
58
29
11/2/2011
Review questions (2)

1. 2. 3. 4.
5.
6.
7.
8.
What are the main roles of playout buffer ? Describe the operation of linked-list of buffer nodes ? List the main reasons of clock skew ? How many steps involved in calculating playout time ? Describe these steps ? What happens to RTP packets while traversing through the network ? What happens to RTP packets that arrive later than displayed packets ? Assuming a multipoint video & audio conference of 4 participants, where all participants can see and talk to one another. How many input queues that an application should maintain ? Describe the relationship between RTP packet size and network MTU ?
11/2/2011
59
Quality of Service in Multimedia network
11/2/2011
60
30
11/2/2011
Traffic Scheduling & Policing: Int-Serv, Diff-Serv, RSVP
IETF groups are working on proposals to improve QoS control in IP networks, i.e., going beyond best effort to provide some assurance for QOS Work in Progress includes RSVP, Differentiated Services, and Integrated Services Simple model for sharing and congestion studies
11/2/2011
61
Principles for QOS Guarantees
Consider a phone application at 1Mbps and an FTP application sharing a 1.5 Mbps link. Bursts of FTP can congest the router and cause audio packets to be dropped want to give priority to audio over FTP !! PRINCIPLE 1: Marking of packets is needed for router to distinguish between different classes; and new router policy to treat packets accordingly
31
11/2/2011
Principles for QOS Guarantees (2)
Applications misbehave (audio sends packets at a rate higher than 1Mbps assumed above); PRINCIPLE 2: provide protection (isolation) for one class from other classes Require Policing Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges:
Alternative to Marking and Policing: allocate a set portion of bandwidth to each application flow; can lead to inefficient use of bandwidth if one of the flows does not use its allocation PRINCIPLE 3: While providing isolation, it is desirable to use resources as efficiently as possible
32
11/2/2011
Cannot support traffic beyond link capacity PRINCIPLE 4: Need a Call Admission Process; application flow declares its needs, network may block call if it cannot satisfy the needs
Summary
11/2/2011
66
33
11/2/2011
Scheduling And Policing Mechanisms

Scheduling: choosing the next packet for transmission on a link can be done following a number of policies; FIFO: in order of arrival to the queue; packets that arrive to a full buffer are either discarded, or a discard policy is used to determine which packet to discard among the arrival and those already queued
11/2/2011
67
Scheduling Policies
Priority Queuing: classes have different priorities; class may depend on explicit marking or other header info, eg IP source or destination, TCP Port numbers, etc. Transmit a packet from the highest priority class with a non-empty queue Preemptive and non-preemptive versions
34
11/2/2011
Scheduling Policies (2)

Round Robin: scan class queues serving one from each class that has a non-empty queue
11/2/2011
69
Scheduling Policies (3)

Weighted Fair Queuing: is a generalized Round Robin in which an attempt is made to provide a class with a differentiated amount of service over a given period of time
11/2/2011
70
35
11/2/2011
Policing Mechanisms
Three criteria:
(Long term) Average Rate (100 packets per sec or 6000 packets per min??), crucial aspect is the interval length Peak Rate: e.g., 6000 p p minute Avg and 1500 p p sec Peak (Max.) Burst Size: Max. number of packets sent consecutively, ie over a short period of time
Policing Mechanisms
Token Bucket mechanism, provides a means for limiting input to specified Burst Size and Average Rate.
11/2/2011
72
36
11/2/2011
Policing Mechanisms (2)

Bucket can hold b tokens; token are generated at a rate of r token/sec unless bucket is full of tokens. Over an interval of length t, the number of packets that are admitted is less than or equal to (r t + b). Token bucket and WFQ can be combined to provide upper bound on delay.
Integrated Services
An architecture for providing QOS guarantees in IP networks for individual application sessions Relies on resource reservation, and routers need to:
Maintain state info (Virtual Circuit) maintaining records of allocated resources and.. Respond to new Call setup requests on that basis
37
11/2/2011
Call Admission
Session must first declare its QOS requirement and characterize the traffic it will send through the network R-spec: defines the QOS being requested T-spec: defines the traffic characteristics A signaling protocol is needed to carry the Rspec and T-spec to the routers where reservation is required RSVP is a leading candidate for such signaling protocol
11/2/2011
75
Call Admission
Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.
11/2/2011
76
38
11/2/2011
Integrated Services: Classes

Guaranteed QOS: this class is provided with firm bounds on queuing delay at a router; envisioned for hard real-time applications that are highly sensitive to end-to-end delay expectation and variance Controlled Load: this class is provided a QOS closely approximating that provided by an unloaded router; envisioned for todays IP network real-time applications which perform well in an unloaded network
Differentiated Services
Intended to address the following difficulties with Intserv and RSVP; Scalability: maintaining states by routers in high speed networks is difficult sue to the very large number of flows Flexible Service Models: Intserv has only two classes, want to provide more qualitative service classes; want to provide relative service distinction (Platinum, Gold, Silver, ) Simpler signaling: (than RSVP) many applications and users may only want to specify a more qualitative notion of service
39
11/2/2011
Differentiated Services
Approach:
Only simple functions in the core, and relatively complex functions at edge routers (or hosts) Do not define service classes, instead provides functional components with which service classes can be built
11/2/2011
79
Edge Functions
At DS-capable host or first DS-capable router Classification: edge node marks packets according to classification rules to be specified (manually by admin, or by some TBD protocol) Traffic Conditioning: edge node may delay and then forward or may discard
40
11/2/2011
Core Functions
Forwarding: according to Per-HopBehavior or PHB specified for the particular packet class; such PHB is strictly based on class marking (no other header fields can be used to influence PHB) BIG ADVANTAGE: No state info to be maintained by routers!
11/2/2011
81
Classification and Conditioning

Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive 2 bits are currently unused
11/2/2011
82
41
11/2/2011
Classification and Conditioning

It may be desirable to limit traffic injection rate of some class; user declares traffic profile (eg, rate and burst size); traffic is metered and shaped if non-conforming
11/2/2011
83
Forwarding (PHB)
PHB result in a different observable (measurable) forwarding performance behavior PHB does not specify what mechanisms to use to ensure required PHB performance behavior Examples:
Class A gets x% of outgoing link bandwidth over time intervals of a specified length Class A packets leave first before packets from class B
42
11/2/2011
Forwarding (PHB)
PHBs under consideration:
Expedited Forwarding (EF): departure rate of packets from a class equals or exceeds a specified rate (logical link with a minimum guaranteed rate) Assured Forwarding (AF): 4 classes, each guaranteed a minimum amount of bandwidth and buffering; each with three drop preference partitions
11/2/2011
85
Differentiated Services Issues

AF and EF are not even in a standard track yet research ongoing Virtual Leased lines and Olympic services are being discussed Impact of crossing multiple ASs and routers that are not DS-capable
11/2/2011
86
43
11/2/2011
Key points of Chapter 1

RTP & RTCP
Media transmission and reception over network Translator & Mixer RTP Session RTP Stream RTP Packet format
SSRC & CSRC
QoS:
Scheduling
WFQ
Policing:
Token Bucket
Packet Classifications
DSCP/TOS
Call Admission
T-Spec/R-Spec
Int-Serv
RSVP
Diff-Serv
Forwarding PHB
AF/EF
RTCP packet format

SR/RR/SDES/BYE/APP
11/2/2011
DSCP
Int-Serv vs. Diff-Serv
87
Technical terms
RTCP SSRC CSRC SDES RSVP DiffServ IntServ WFQ = Weight Fair Queuing PHB = Per hop behavior
11/2/2011
DSCP = Differentiated Service Code Point TOS = Type of Service
88
44
11/2/2011
Chapter 2: Multimedia applications Voice and Video over IP

Roadmap
Streaming applications VoIP archiecture VoIP issues SIP protocol SIP applications
11/2/2011
89
Streaming applications
Important and growing application due to:
Reduction of storage costs, Broadband Internet access Enhancements of caching More QoS suports in IP-based networks
Applications:
IPTV, VoD (Video on Demand) Internet Radio
Audio/Video file is segmented and sent over either TCP or UDP, public segmentation protocol: RealTime Protocol (RTP)
45
11/2/2011
Streaming Stored Audio & Video

Streaming stored media: Audio/video file is stored in a server Users request audio/video file on demand. Audio/video is rendered within, say, 10 s after request. Interactivity (pause, repositioning, etc.) is allowed.
11/2/2011
Media player:
removes jitter decompresses error correction graphical user interface with controls for interactivity
Plug-ins may be used to imbed the media player into the browser window.
91
Streaming
User interactive control is provided, e.g. the public protocol Real Time Streaming Protocol (RTSP) Helper Application: displays content, which is typically requested via a Web browser; e.g. RealPlayer; typical functions:
Decompression Jitter removal Error correction: use redundant packets to be used for reconstruction of original stream GUI for user control
46
11/2/2011
Streaming From Web Servers

Audio: in files sent as HTTP objects Video (interleaved audio and images in one file, or two separate files and client synchronizes the display) sent as HTTP object(s) A simple architecture is to have the Browser requests the object(s) and after their reception pass them to the player for display - No pipelining
Streaming From Web Server (2)

Alternative: set up connection between server and player, then download Web browser requests and receives a Meta File ( a file describing the object) instead of receiving the file itself; Browser launches the appropriate Player and passes it the Meta File; Player sets up a TCP connection with Web Server and downloads the file
47
11/2/2011
Meta file requests
11/2/2011
95
Using a Streaming Server

This gets us around HTTP, allows a choice of UDP vs. TCP and the application layer protocol can be better tailored to Streaming; many enhancements options are possible (see next slide)
11/2/2011
96
48
11/2/2011
Options When Using a Streaming Server

Use UDP, and Server sends at a rate (Compression and Transmission) appropriate for client; to reduce jitter, Player buffers initially for 2-5 seconds, then starts display Use TCP, and sender sends at maximum possible rate under TCP; retransmit when error is encountered; Player uses a much large buffer to smooth delivery rate of TCP
11/2/2011
97
Real Time Streaming Protocol (RTSP)

For user to control display: rewind, fast forward, pause, resume, etc Out-of-band protocol (uses two connections, one for control messages (Port 554) and for media stream) RFC 2326 permits use of either TCP or UDP for the control messages connection, sometimes called the RTSP Channel As before, meta file is communicated to web browser which then launches the Player; Player sets up an RTSP connection for control messages in addition to the connection for the streaming media
49
11/2/2011
Meta File Example

<title>Twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session>
11/2/2011
99
SDP Session Description Protocol

RFC 4566
11/2/2011
100
50
11/2/2011
RTSP Operation
11/2/2011
101
RTSP Exchange Example

C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OK
51
11/2/2011
Real-World Streaming Applications

What material can be streamed ?
Video/Audio (File or Live source) Presentation slides Combinations
Real
Most OSes Windows only MacOS/Win32/Some UNIXes
Server: Helix Universal Server + Helix Producer Client: Real Player
Microsoft Apple
Server: Windows Media Server/Encoder Client: Windows Media Player Server: Darwin Server Client: QuickTime
Adobe Flash
Server: Flash Communication Server Client: Flash plug-in in most Web browser
Hand-ons excercises:
Setup your own streaming server to serve movies, music and real-time TV programs for your friends on ADSL access network
Technology Demo
Darwin streaming server
SDP Playlist Ethereal capture
Client QuickTime/ Realplayer (Mobile Phone)
11/2/2011
104
52
11/2/2011
Internet Telephony VoIP & VideoIP
11/2/2011
105
Internet telephony
11/2/2011
106
53
11/2/2011
VoIP archiecture
11/2/2011
107
Protocols needed
11/2/2011
108
54
11/2/2011
Protocol
11/2/2011
109
11/2/2011
110
55
11/2/2011
11/2/2011
111
Session Initiation Protocol (SIP)
11/2/2011
112
56
11/2/2011
What is SIP?
Session Initiation Protocol - An application layer signaling protocol that defines initiation, modification and termination of interactive, multimedia communication sessions between users.
IETF RFC 2543 Session Initiation Protocol
113
11/2/2011
Sip end-devices
11/2/2011
114
57
11/2/2011
SIP Framework
Session initiation. Multiple users. Interactive multimedia applications.
11/2/2011
115
SIP Distributed Architecture
SIP Components
Location Server
Redirect Server
Registrar Server
PSTN
User Agent Proxy Server
11/2/2011
Gateway Proxy Server

116
58
11/2/2011
Proxy Server
An intermediary program that acts as both a server and a client to make requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. Interprets, rewrites or translates a request message before forwarding it.
Location Server
A location server is used by a SIP redirect or proxy server to obtain information about a called partys possible location(s).
11/2/2011
118
59
11/2/2011
Redirect Server
A server that accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server, the redirect server does not initiate its own SIP request. Unlike a user agent server, the redirect server does not accept or terminate calls.
Registrar Server
A server that accepts REGISTER requests. The register server may support authentication. A registrar server is typically co-located with a proxy or redirect server and may offer location services.
11/2/2011
120
60
11/2/2011
Structure of SIP
* User ISO 10646 , character set in UTF8 Method Method Request URI SIP version
* The format of the Response message header Method SIP version Status code Reason-pharse
11/2/2011
121
SIP Messages Methods and Responses

SIP components communicate by exchanging SIP messages:
SIP Methods:
INVITE Initiates a call by inviting user to participate in session. ACK - Confirms that the client has received a final response to an INVITE request. BYE - Indicates termination of the call. CANCEL - Cancels a pending request. REGISTER Registers the user agent. OPTIONS Used to query the capabilities of a server. INFO Used to carry out-ofbound information, such as DTMF digits.
SIP Responses:
1xx - Informational Messages. 2xx - Successful Responses. 3xx - Redirection Responses. 4xx - Request Failure Responses. 5xx - Server Failure Responses. 6xx - Global Failures Responses.
11/2/2011
122
61
11/2/2011
SIP Headers
SIP borrows much of the syntax and semantics from HTTP. A SIP messages looks like an HTTP message message formatting, header and MIME support. An example SIP header:
----------------------------------------------------------------SIP Header ----------------------------------------------------------------INVITE sip:5120@192.168.36.180 SIP/2.0 Via: SIP/2.0/UDP 192.168.6.21:5060 From: sip:5121@192.168.6.21 To: <sip:5120@192.168.36.180> Call-ID: c2943000-e0563-2a1ce-2e323931@192.168.6.21 CSeq: 100 INVITE Expires: 180 User-Agent: Cisco IP Phone/ Rev. 1/ SIP enabled Accept: application/sdp Contact: sip:5121@192.168.6.21:5060 Content-Type: application/sdp
SIP Addressing
The SIP address is identified by a SIP URL, in the format: user@host. Examples of SIP URLs:
sip:hostname@hut.edu.vn sip:hostname@192.168.10.1 sip:14083831088@hut.edu.vn
11/2/2011
124
62
11/2/2011
Process for Establishing Communication

Establishing communication using SIP usually occurs in 6 steps: 1. Registering, initiating and locating the user. 2. Determine the media to use involves delivering a description of the session that the user is invited to. 3. Determine the willingness of the called party to communicate the called party must send a response message to indicate willingness to communicate accept or reject. 4. Call setup. 5. Call modification or handling example, call transfer (optional). 6. Call termination.
Registration
Each time a user turns on the SIP user client (SIP IP Phone, PC, or other SIP device), the client registers with the proxy/registration server. Registration can also occur when the SIP user client needs to inform the proxy/registration server of its location. The registration information is periodically refreshed and each user client must re-register with the proxy/registration server. Typically the proxy/registration server will forward this information to be saved in the location/redirect server.
11/2/2011
SIP Phone User REGISTER 200
Proxy/ Registration Server REGISTER 200
Location/ Redirect Server
SIP Messages: REGISTER Registers the address listed in the To header field. 200 OK.
126
63
11/2/2011
Simplified SIP Call Setup and Teardown
11/2/2011
127
127
SIP Design Framework

SIP was designed for:
Integration with existing IETF protocols. Scalability and simplicity. Mobility. Easy feature and service creation.
11/2/2011
128
64
11/2/2011
11/2/2011
129
Call flow SIP to PSTN
11/2/2011
130
65
11/2/2011
Technology Demo
Asterisk VoIP system Linux
SIP config SIP calls Asterisk CLI
Client
X-Lite Mobile Phone, SIP Client Nokia
11/2/2011
131
VoIP issues
Internet phone applications generate packets during talk spurts Bit rate is 8 KBytes, and every 20 msec, the sender forms a packet of 160 Bytes + a header The coded voice information is encapsulated into a UDP packet and sent out Some packets may be lost up to 20 % loss is tolerable Using TCP eliminates loss but cause variance in delay FEC is sometimes used to fix errors and make up losses
66
11/2/2011
Real-Time (Phone) Over IPs Best-Effort

End-to-end delays above 400 msec cannot be tolerated delayed packets are ignored at the receiver ! Delay jitter is handled by using
timestamps, sequence numbers,
Delaying playout at receivers either a fixed or a variable amount With fixed playout delay, the delay should be as small as possible without missing too many packets; delay cannot exceed 400 msec
Internet Phone with Fixed Playout Delay
11/2/2011
134
67
11/2/2011
Adaptive Playout Delay

The objective is to use a value for p-r that tracks the network delay performance as it varies during a phone call The playout delay is computed for each talk spurt based on observed average delay and observed deviation from this average delay Estimated average delay and deviation of average delay are computed in a manner similar to estimates of RTT and deviation in TCP The beginning of a talk spurt is identified from examining the timestamps in successive and/or sequence numbers of chunks
Techniques to deal with packet Loss

Loss is in a broader sense: packet never arrives or arrives later than its scheduled playout time Since retransmission is inappropriate for Real FEC (Forward Error Time applications, Correction) or Interleaving are used to reduce loss impact. Simplest FEC scheme adds a redundant chunk made up of exclusive OR of a group of n chunks; redundancy is 1/n; can reconstruct if at most one lost chunk; playout time schedule assumes a loss per group
68
11/2/2011
Techniques to deal with packet Loss (2)

Mixed quality streams are used to include redundant duplicates of chunks; upon loss playout available redundant chunk, albeit a lower quality one With one redundant chunk per chunk can recover from single losses
11/2/2011
137
Piggybacking Lower Quality Stream
11/2/2011
138
69
11/2/2011
Interleaving
Has no redundancy, but can cause delay in playout beyond Real Time requirements Divide 20 msec of audio data into smaller units of 5 msec each and interleave Upon loss, have a set of partially filled chunks
11/2/2011
139
70

AdvMultiMedia2k7 01H

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AdvMultiMedia2k7 01H

Загружено:

Авторское право:

Доступные форматы

11/2/2011

Advanced Multimedia Technology

Chapter 2: Voice and Video Over IP

Chapter 3: MPEG-4 & H264

Nguyen Chan Hung Hanoi University of Technology

Nguyen Chan Hung Hanoi University of Technology

Nguyen Chan Hung Hanoi University of Technology

Chapter 1: Multimedia networks

Nguyen Chan Hung Hanoi University of Technology

Multimedia requirements App classes

Nguyen Chan Hung Hanoi University of Technology

Making the best of best effort Internet

Nguyen Chan Hung Hanoi University of Technology

Internet evolution to better support multimedia

Requires new, complex software in hosts & routers

Nguyen Chan Hung Hanoi University of Technology

Internet evolution to better support multimedia (2)

Nguyen Chan Hung Hanoi University of Technology

RTP & RTCP

Nguyen Chan Hung Hanoi University of Technology

Real-Time Protocol (RTP)

Nguyen Chan Hung Hanoi University of Technology

Fundamental Design Philosophies of RTP

Nguyen Chan Hung Hanoi University of Technology

By using application-level framing with UDP-based transport, multimedia applications can:

Nguyen Chan Hung Hanoi University of Technology

The End-to-End Principle

Nguyen Chan Hung Hanoi University of Technology

The RTP Specifications

Nguyen Chan Hung Hanoi University of Technology

RTP and OSI model

Nguyen Chan Hung Hanoi University of Technology

RTP and related standards

Nguyen Chan Hung Hanoi University of Technology

Nguyen Chan Hung Hanoi University of Technology

Types of RTP Sessions

Nguyen Chan Hung Hanoi University of Technology

RTP header also contains sequence numbers and timestamps.

Nguyen Chan Hung Hanoi University of Technology

RTP Implementations (2)

RTP receiver Receiver is responsible for:

RTP and QoS

Nguyen Chan Hung Hanoi University of Technology

Nguyen Chan Hung Hanoi University of Technology

Nguyen Chan Hung Hanoi University of Technology

Nguyen Chan Hung Hanoi University of Technology

Nguyen Chan Hung Hanoi University of Technology

RTP packet format

Nguyen Chan Hung Hanoi University of Technology

RTP packet format (2)

Nguyen Chan Hung Hanoi University of Technology

RTP packet format (3)

Nguyen Chan Hung Hanoi University of Technology

RTP packet format (4)

Real-Time Control Protocol (RTCP)

Nguyen Chan Hung Hanoi University of Technology

Nguyen Chan Hung Hanoi University of Technology

RTCP packet format

Nguyen Chan Hung Hanoi University of Technology

RTCP packet format (2)

RTCP Packets - Overview

Nguyen Chan Hung Hanoi University of Technology