UNIT-4

Multimedia Communications

4.1 QUALITY OF MULTIMEDIA DATA TRANSMISSION

Characteristics of Multimedia Data

1. Voluminous —they demand very high datarates, possibly dozens or hundreds of Mbps.
2. Real-time and interactive—they demand low delay and synchronization between audio
and video for “lipsync”. In addition, applications such as video conferencing and
interactive multimedia also require two-way traffic.
3. Sometimes bursty—datarates fluctuate drastically, e.g., no traffic most of the time but
burst to high volume in video on-demand.

4.1.1 Quality of Service (QoS)

Quality of Service (QoS) for multimedia data transmission depends on many parameters. Some
of the most important are:

1. Data Rate. A measure of transmission speed, often in kilobits per second (kbps) or
megabits per second (Mbps)
2. Latency (maximum frame/packet delay). Maximum time needed from transmission to
reception, often measured in milliseconds (msec). In voice communication, for example,
when the round - trip delay exceeds 50 msec, echo becomes a noticeable problem; when
the one - way delay is longer than 250 msec, talker overlap will occur, since each caller
will talk without knowing the other is also talking.
3. Packet loss or error. A measure (in percentage) of error rate of the packetized data
transmission. Packets get lost or garbled, such as over the Internet. They may also be
delivered late or in the wrong order. Since retransmission is often undesirable, a simple
error - recovery method for real - time multimedia is to replay the last packet, hoping the
error is not noticeable.

FIGURE 4.1: Jitters in frame playback: (a) high jitter; (b) low jitter

In general, for uncompressed audio / video, the desirable packet loss is < 10 - 2 (lose every
hundredth packet, on average). When it approaches 10%, it becomes intolerable. For compressed
multimedia and ordinary data, the desirable packet loss is less than 10 - 7 to 10 - 8.

4. Jitter (or delay jitter). A measure of smoothness of the audio / video playback.
Technically, jitter is related to the variance of frame / packet delays. A large buffer (jitter
buffer) can to hold enough frames to allow the frame with the longest delay to arrive, to
reduce playback jitter. However, this increases the latency and may not be desirable in
 real - time and interactive applications. The above figure illustrates examples of high and
low jitters in frame playbacks.

5. Sync skew. A measure of multimedia data synchronization, often measured in

milliseconds (msec). For a good lip synchronization, the limit of sync skew is ±80 msec
between audio and video. In general, ±200 msec is still acceptable. For a video with
speaker and voice the limit of sync skew is 120 msec if video precedes voice and 20 msec
if voice precedes video. (The discrepancy is probably because we are used to have sound
lagging image at a distance.)

4.1.2 Multimedia Service Classes

Multimedia Service Classes Based on the above measures, multimedia applications can be
classified into the following types:

1. Real - Time (also Conversational). Two - way traffic, low latency and jitter, possibly with
prioritized delivery, such as voice telephony and video telephony

2. Priority data. Two - way traffic, low loss and low latency, with prioritized delivery, such as
e-commerce applications

Table 4.1 Requirement on network bandwidth / bitrate

3. Silver. Moderate latency and jitter, strict ordering and sync. One - way traffic, such as
streaming video; or two - way traffic (also Interactive), such as web surfing and internet
games
4. Best Effort (also Background). No real - time requirement, such as downloading or
transferring large files (movies)

5. Bronze. No guarantees for transmission

4.1.3 Perceived QoS.

Although QoS is commonly measured by the above technical parameters, QoS itself is a
"collective effect of service performances that determine the degree of satisfaction of the user of
that service," as defined by the International Telecommunications Union. In other words, it has
everything to do with how the user perceives it.

In real - time multimedia, regularity is more important than latency (i.e., jitter and quality
fluctuation are more annoying than slightly longer waiting); temporal correctness is more
important than the sound and picture quality (i.e., ordering and synchronization of audio and
video are of primary importance); and humans tend to focus on one subject at a time.

User focus is usually at the center of the screen, and it takes time to refocus, especially after a
scene change. Together with the perceptual nonuniformity we have studied in previous chapters,
many issues of perception can be exploited in achieving the best perceived QoS in networked
multimedia.

Table 4.2 Tolerance of latency and jitter in digital audio and video

4.1.4 QoS for IP Protocols

1. IP is a best-effort communications technology—hard to provide QoS over IP by current

routing methods.

• Abundant bandwidth improves QoS, but unlikely to be available everywhere over a

complex networks.
• Frame relay routing protocol and ATM provide some levels of QoS, but currently most
Internet applications are built on IP.

2. Differentiated Service (DiffSety) uses DiffServ code [Type of Service (TOS) octet in IPv4
packet and Traffic Class octet in IPv6 packet] to classify packets to enable their differentiated
treatment,
• widely deployed in intra domain networks and enterprise networks, as it is simpler
and scales well, it is also applicable to end - to - end networks
• DiffServ, in conjunction with other QoS techniques, is emerging as the de facto QoS
technology.

3. Multiple Protocol Label Switching (MPLS) facilitates the marriage of IP to OSI layer 2
technologies, such as ATM, by overlaying a protocol on top of IP. It introduces a 32 - bit
 label and inserts one or more shim labels into the header of an IP packet in a backbone IP
network. It thus creates tunnels, called Label Switched Paths (LSP). By doing so, the
backbone IP network becomes connection - oriented.

• Creates tunnels: Label Switched Paths (LSP) —IP network becomes connection-oriented.
• Main advantages of MPLS:
a. Support Traffic Engineering (TE), which is used essentially to control traffic flow.
b. Support VPN (Virtual Private Network).
c. Both TE and VPN help delivery of QoS for multimedia data.
4. DiffServ and MPLS can be used together to allow better control of both QoS performance
per class and provision of bandwidth, retaining advantages of both MPLS and DiffServ.

4.1.5 Prioritized Delivery

Used to alleviate the perceived deterioration (high packet loss or error rate) in network
congestion.

1. Prioritization for types of media. Transmission algorithms can provide prioritized

delivery to different media for example, giving higher priority to audio than to video
;since loss of content in audio is often more noticeable than in video.
2. Prioritization for uncompressed audio. PCM audio bitstreams can be broken into groups
of every nth sample prioritize and send k of the total of n groups (k ≤ n) and ask the
receiver to interpolate the lost groups if so desired. For example, if two out of four groups
are lost, the effective sampling rate is 22.05 kHz instead of 44.1 kHz. Loss is perceived
as change in sampling rate, not dropouts.
3. Prioritization for JPEG image. The different scans in Progressive JPEG and different
resolutions of the image in Hierarchical JPEG can be given different priorities, for
example, highest priority for the scan with the DC and first few AC coefficients, and
higher priority to lower - re solution components of the Hierarchical JPEG image.
4. Prioritization for compressed video. Video prioritization algorithms can set priorities to
minimize playback delay and jitter by giving the highest priority to reception of I - frames
and the lowest priority to B - frames. In scalable video (such as MPEG - 2 and 4) using
layered coding, the base layer can be given higher priority than the enhancement layers.

4.2 MULTIMEDIA OVER IP

A broadcast message is sent to all nodes in the domain, a unicast message is sent to only one
node, and a multicast message is sent to a set of specified nodes.

• IP – Multicast
- Anonymous membership: the source host multicasts to one of the IP-multicast
addresses—doesn’t know who will receive.
- Potential problem: too many packets will be traveling and a live in the network—use
time-to-live (TTL) in each IP packet.

FIGURE 4.2: Tunnels for IP Multicast in MBone

- One of the first trials of IP - multicast was in March 1992, when the Internet Engineering
Task Force (IETF) meeting in San Diego was broadcast (audio only) on the Internet.

• MBone. The Internet Multicast Backbone (MBone) is based on IP - multicast technology.

Starting in the early 1990s, it has been used, for example, for audio and video
conferencing on the Internet. Earlier applications include vat for audio conferencing, vic
and nv for video conferencing. Other application tools include wb for whiteboards in
shared workspace and sdr for maintaining session directories on MBone.

MBone (Multicast Backbone)—based on the IP-multicast technology:

- Used for audio and video conferencing on the Internet.

- Uses a subnetwork of routers (mrouters) that support multicast to forward multicast
packets.
Drawback of multicasting:

- Too many packets will be traveling and alive in the network. Fortunately, IP packets have
a time - to - live (TTL) field that limits the packet's lifetime. Each router decrements the
TTL of the pass - by packet by at least one. The packet is discarded when its TTL is zero.

The IP - multicast method described above is based on UDP (not TCP), so as to avoid excessive
acknowledgments from multiple receivers for every message. As a result, packets are delivered
by "best effort", so reliability is limited.

4.2.1 Internet Group Management Protocol (IGMP)

1. Designed to help the maintenance of multicast groups.

2. Two special types of IGMP messages are used: – Query messages are multicast by routers
to all local hosts to inquire group membership.
a. Report is used to respond to query, and to join groups.
3. On receiving a query, members wait for a random time before responding.
4. Routers periodically query group membership, and declare themselves group members if
they get a response to atleast one query. If no responses occur after a while, they declare
themselves as non-members. Reliable Multicast Transport. IETF RFC 2357 was an attempt
to define criteria for evaluating reliable IP - multicast protocols.

MB one maintains a flat virtual topology and does not provide good route aggregation (at the
peak time, MBone had approximately 10,000 routes). Hence, it is not scalable. Moreover, the
original design is highly distributed (and simplistic). It assumes no central management, which
results in ineffective tunnel management, that is, tunnels connecting islands are not optimally
allocated. Sometimes multiple tunnels are created over a single physical link, causing congestion.

4.2.2 RTP (Real - time Transport Protocol)

The original Internet design provided "best - effort" service and was adequate for applications
such as e - mail and FTP. However, it is not suitable for real - time multimedia applications.

1. Designed for the transport of real-time data such as audio and video streams:
- Primarily intended for multicast.
- Used in nv (network video) for MBone, Netscape Live Media, Microsoft Net meeting,
and Intel Videophone.
2. Usually runs on top of UDP which provides efficient (but less reliable) connectionless
datagram service :
 - RTP must create its own timestamping and sequencing mechanisms to ensure the
ordering.

Since "UDP will not guarantee that the data packets arrive in the original order (not to mention
synchronization of multiple sources), RTP must create its own time stamping and sequencing
mechanisms to ensure the ordering.

4.2.3 Additional Parameters in RTP Header

RTP introduces the following additional parameters in the header of each packet:

1. Payload type indicates the media data type as well as its encoding scheme (e.g., PCM,
H.261 / H.263, MPEG 1, 2, and 4 audio / video, etc.) so the receiver knows how to decode
it.
2. Timestamp is the most important mechanism of RTP. The timestamp records the instant
when the first octet of the packet is sampled; it is set by the sender. With the timestamps,
the receiver can play the audio / video in proper timing order and synchronize multiple
streams (e.g., audio and video) when necessary.
3. Sequence number is to complement the function of timestamping. It is incremented by
one for each RTP data packet sent, to ensure that the packets can be reconstructed in order
by the receiver. This becomes necessary, for example, when all packets of a video frame
sometimes receive the same timestamp, and timestamping alone becomes insufficient.
4. Synchronization source (SSRC) ID identifies sources of multimedia data (e.g., audio,
video). If the data come from the same source (translator, mixer), they will be given the
same SSRC ID, so as to be synchronized.
5. Contributing Source (CSRC) ID identifies the source of contributors, such as all speakers
in an audio conference.

The following figure 4.3 shows the RTP header format. The first 12 octets are of fixed format,
followed by optional (0 or more) 32 - bit Contributing Source (CSRC) IDs.

Bits 0 and 1 are for the version of RTP, bit 2 (P) for signaling a padded payload, bit 3 (X) for
signaling an extension to the header, and bits 4 through 7 for a 4 - bit CSRC count that indicates
the number of CSRC IDs following the fixed part of the header.

Bit 8 (M) signals the first packet in an audio frame or last packet in a video frame, since an audio
frame can "be played out as soon as the first packet is received, whereas a video frame can be
rendered only after the last packet is received. Bits 9 through 15 describe the payload type, Bits
16 through 31 are for sequence number, and followed by a 32 - bit timestamp and a 32 - bit
Synchronization Source (SSRC) ID.
 FIGURE 4.3: RTP packet header

4.2.4 Real Time Control Protocol (RTCP)

RTCP gathers statistics for a media connection and information such as transmitted octet and
packet counts, lost packet counts, jitter, and round - trip delay time. An application may use this
information to control quality of service parameters, perhaps by limiting flow, or using a different
codec.

1. A companion protocol of RTP:

- Monitors QoS in providing feedback to the server (sender) and conveys information
about the participants of a multiparty conference.
- Provides the necessary information for audio and video synchronization.
2. RTP and RTCP packets are sent to the same IP address (multicast or unicast) but on
different ports.
3. Is a sister protocol of the Real - time Transport Protocol (RTP).
4. Its basic functionality and packet structure is defined in the RTP specification RFC 3550,
superseding its original standardization in 1996 (RFC 1889).
5. Provides out - of - band statistics and control information for an RTP flow.
6. It partners RTP in the delivery and packaging of multimedia data, but does not transport
any media streams itself.
7. Typically RTP will be sent on an even - numbered UDP port, with RTCP messages being
sent over the next higher odd - numbered port.
8. Provide feedback on the quality of service (QoS) in media distribution by periodically
sending statistics information to participants in a streaming multimedia session.
9. It does not provide any flow encryption or authentication methods. Such mechanisms may
be implemented, for example, with the Secure Real - time Transport Protocol (SRTP)
defined in RFC 3711.
The five types of RTCP packets are as below.

1. Receiver report (RR) provides quality feedback (number of last packet received, number
of lost packets, jitter, and timestamps for calculating round - trip delays).

2. Sender report (SR) provides information about the reception of RR, number of packets /
bytes sent, and so on.

3. Source description (SDES) provides information about the source (e - mail address,
phone number, full name of the participant).Bye indicates the end of participation.

4. Application specific functions (APP) provides for future extension of new features. RTP
and RTCP packets are sent to the same IP address (multicast or unicast) but on different
ports.

5. Bye —the end of participation.

4.2.5 Resource Reservation Protocol (RSVP)

1. Developed to guarantee desirable QoS, mostly for multicast although also applicable to
unicast.

– A general communication model supported by RSVP consists of m senders and n receivers,

possibly in various multicast groups (e.g.Fig.4.4 (a)).

2. The most important messages of RSVP:

(1)A Path message is initiated by the sender, and contains information about the sender and the
path (e.g., the previous RSVP hop).

(2)A Resv message is sent by a receiver that wishes to make a reservation.

The Resource Reservation Protocol (RSVP) is a Transport Layer protocol designed to reserve
resources across a network for an integrated services Internet. RSVP operates over an IPv4 or
IPv6 Internet Layer and provides receiver - initiated setup of resource reservations for multicast
or unicast data flows with scaling and robustness. It does not transport application data but is
similar to a control protocol, like ICMP or IGMP.

RSVP can be used by either hosts or routers to request or deliver specific levels of quality of
service (QoS) for application data streams or flows. RSVP defines how applications place
reservations and how they can relinquish the reserved resources once the need for them has
ended. RSVP operation will generally result in resources being reserved in each node along a
path.

RSVP is not a routing protocol and was designed to interoperate with current and future routing
protocols. RSVP by itself is rarely deployed in telecommunication networks today but the traffic
engineering extension of RSVP, or RSVPTE, is becoming more widely accepted nowadays in
many QoS - oriented networks. Next Steps in Signaling (NSIS) is a replacement for RSVP.
Main Challenges of RSVP

(a)There can be a large number of senders and receivers competing for the limited network
bandwidth.

(b)The receivers can be heterogeneous in demanding different contents with different QoS.

(c)They can be dynamic by joining or quitting multicast groups at anytime.

FIGURE 4.4: A scenario of network resource reservation with RS VP: (a) senders S1 and S2
send out their PATH messages to receivers Rl, R2, and R3; (b) receiver Rl sends out RESV
message to SI; (c) receiver R2 sends out RESV message to S2; (d) receivers R2 and R3 send
out their RESV messages to SI

The most important messages of RSVP are Path and Resv. A Path message is initiated by the
sender and travels towards the multicast (or unicast) destination addresses. It contains
information about the sender and the path (e.g., the previous RSVP hop), so the receiver can find
the reverse path to the sender for resource reservation. A Resv message is sent by a receiver that
wishes to make a reservation.

RSVP is receiver - initiated. A receiver (at a leaf of the multicast spanning tree) initiates the
reservation request Resv, and the request travels back toward the sender but not necessarily all
the way. A reservation will be merged with an existing reservation made by other receiver(s) for
the same session as soon as they meet at a router. The merged reservation will accommodate the
highest bandwidth requirement among all merged requests. The user - initiated scheme is highly
scalable, and it meets users' heterogeneous needs.

RSVP creates only soft state. The receiver host must maintain the soft state by periodically
sending the same Resv message; otherwise, the state will time out. There is no distinction
between the initial message and any subsequent refresh message. If there is any change in
reservation, the state will automatically be updated according to the new reservation parameters
in the refreshing message. Hence, the RSVP scheme is highly dynamic.

Fig 4.4 depicts a simple network with 2 senders (S1,S2), three receivers (R1,R2,andR3) and 4
routers (A,B,C,D):

1. In (a), Path messages are sent by bothS1 and S2 along their paths to R1,R2, and R3.

2. In (b) and (c), R1 and R2 send out Resv messages to S1 and S2 respectively to make
reservations for S1 and S2 resources. Note that from C to A, two separate channels must be
reserved since R1 and R2 requested different data streams.

3. In (d), R2 and R3 send out their Resv messages to S1 to make additional requests. R3’s request
was merged with R1’s previous request at A and R2’s was merged withR1’s at C. Any possible
variation of QoS that demands higher bandwidth can be dealt with by modifying the reservation
state parameters.

4.2.6 Real - Time Streaming Protocol (RTSP)

The Real Time Streaming Protocol (RTSP) is a network control protocol designed for use in
entertainment and communications systems to control streaming media servers. The protocol is
used for establishing and controlling media sessions between end points. Clients of media servers
issue VCR - like commands, such as play and pause, to facilitate real - time control of playback
of media files from the server.

Streaming Audio and Video:

 – Audio and video data that are transmitted from a stored media server to the client in a data
stream that is almost instantly decoded.

• RTSP Protocol: for communication between a client and a stored media server(Fig 4.5).

1. Requesting presentation description: the client issues a DESCRIBE request to the Stored
Media Server to obtain the presentation description—media types, frame rate, resolution, codec,
etc.

2. Session setup: the client issues a SETUP to inform the server of the destination IP address,
port number, protocols, TTL (for multicast).

3. Requestingandreceivingmedia:afterreceivingaPLAY,theserver
startedtotransmitstreamingaudio/videodatausingRTP.

4. Sessionclosure:TEARDOWNclosesthesession.

The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP servers
use the Real - time Transport Protocol (RTP) in conjunction with Real - time Control Protocol
(RTCP) for media stream delivery, however some vendors implement proprietary transport
protocols. The RTSP server from Real Networks, for example, also features Real Networks'
proprietary Real Data Transport (RDT).

RTSP was developed by the Multiparty Multimedia Session Control Working Group (MMUSIC
WG) of the Internet Engineering Task Force (IETF) and published as RFC 2326 in 1998. RTSP
using RTP and RTCP allows for the implementation of rate adaption.

Streaming Audio and Video. In the early days, multimedia data was transmitted over the network
(often with slow links) as a whole large file, which would be saved to a disk, then played back.
Nowadays, more and more audio and video data is transmitted from a stored media server to the
client in a datastream that is almost instantly decoded - streaming audio and streaming video.

Usually, the receiver will set aside buffer space to prefetch the incoming stream. As soon as the
buffer is filled to a certain extent, the (usually) compressed data will be uncompressed and played
back. Apparently, the buffer space needs to be sufficiently large to deal with the possible jitter
and to produce continuous, smooth playback. On the other hand, too large a buffer will introduce
unnecessary initial delay, which is especially undesirable for interactive applications such as
audio - or videoconferencing.

A possible scenario of RTSP operations

FIGURE 4.5: The RTSP Protocol. RTSP is for communication between a client and a stored
media server. The above figure illustrates a possible scenario of four RTSP operations:

1. Requesting presentation description. The client issues a DESCRIBE request to the

Stored Media Server to obtain the presentation description, such as, media types (audio,
video, graphics, etc.), frame rate, resolution, codec, and so on, from the server.

2. Session setup. The client issues a SETUP to inform the server of the destination IP
address, port number, protocols, and TTL (for multicast). The session is set up when the
server returns a session ID.

3. Requesting and receiving media. After receiving a PLAY, the server starts to transmit
streaming audio/video data, using RTP. It is followed by a RECORD or PAUSE. Other
VCR commands, such as FAST - FORWARD and REWIND are also supported. During
the session, the client periodically sends an RTCP packet to the server, to provide
feedback information about the QoS received.
 4. Session closure. TEARDOWN closes the session.

4.2.7 Internet Telephony

The Public Switched Telephone Network (PSTN) relies on copper wires carrying analog voice
signals. It provides reliable and low - cost voice and facsimile services. In the eighties and
nineties, modems were a popular means of "data over voice networks". In fact, they were
predominant before the introduction of ADSL and cable modems.

As PCs and the Internet became readily available and more and more voice and data
communications became digital (e.g., in ISDN), "voice over data networks," especially Voice
over IP (VoIP) started to attract a great deal of interest in research and user communities. With
ever - increasing network bandwidth and the ever - improving quality of multimedia data
compression, Internet telephony has become a reality. Increasingly, it is not restricted to voice
(VoIP) — it is about integrated voice, video, and data services.

The main advantages of Internet telephony over POTS are the following:

• It provides great flexibility and extensibility in accommodating integrated services such

as voicemail, audio - and videoconferences, mobile phone, and so on.

• It uses packet switching, not circuit switching; hence, network usage is much more
efficient (voice communication is bursty and VBR - encoded).

• With the technologies of multicast or multipoint communication, multiparty calls are not
much more difficult than two - party calls.

• With advanced multimedia data - compression techniques, various degrees of QoS can
be supported and dynamically adjusted according to the network traffic, an improvement
over the "all or none" service in POTS.

• Good graphics user interfaces can be developed to show available features and services,
monitor call status and progress, and so on.

As the following figure shows, the transport of real - time audio (and video) in Internet telephony
is supported by RTP (whose control protocol is RTCP). Streaming media is handled by RTSP
and Internet resource reservation is taken care of by RSVP.

Internet telephony is not simply a streaming media service over the Internet, because it requires
a sophisticated signaling protocol. A streaming media server can be readily identified by a URI
(Universal Resource Identifier), whereas acceptance of a call via Internet telephony depends on
the callee's current location, capability, availability, and desire to communicate. The following
are brief descriptions of the H.323 standard and one of the most commonly used signaling
protocols, Session Initiation Protocol (SIP).
FIGURE 4.6: Network protocol structure for internet telephony

H.323. H.323 is a standard for packet - based multimedia communication services over networks
(LAN, Internet, wireless network, etc.) that do not provide a guaranteed QoS. It specifies
signaling protocols and describes terminals, multipoint control units (for conferencing), and
gateways for integrating Internet telephony with General Switched Telephone Network (GSTN)
data terminals.

The H.323 signaling process consists of two phases:

• Call setup. The caller sends the gatekeeper (GK) a Registration, Admission and Status
(RAS) Admission Request (ARQ) message, which contains the name and phone number
of the callee. The GK may either grant permission or reject the request, with reasons such
as "security violation" and "insufficient bandwidth".

• Capability exchange. An H.245 control channel will be established, for which the first
step is to exchange capabilities of both the caller and callee, such as whether it is audio,
video, or data; compression and encryption, and so on.

H.323 provides mandatory support for audio and optional support for data and video. It is
associated with a family of related software standards that deal with call control and data
compression for Internet telephony. Following are some of the related standards:

Signaling and Control

• H.225. Call control protocol, including signaling, registration, admissions, packetization

and synchronization of media streams

• H.24S. Control protocol for multimedia communications — forexample, opening and

closing channels for media streams, obtaining gateway between GSTN and Internet
telephony

• H.235. Security and encryption for H.323 and other H.245 - based multimedia terminals

Audio Codecs
 • G.711. Codec for 3.1 kHz audio over 48, 56, or 64 kbps channels. G.711 describes Pulse
Code Modulation for normal telephony
• G.722. Codec for 7 kHz audio over 48, 56, or 64 kbps channels
• G.723.1. Codec for 3.1 kHz audio over 5.3 or 6.3 kbps channels. (The VoIP Forum
adopted G.723.1 as the codec for VoIP.)
• G.728. Codec for 3.1 kHz audio over 16 kbps channels
• G.729, G.729 a. Codec for 3.1 kHz audio over 8 kbps channels. (The Frame Relay Forum
adopted G.729 by as the codec for voice over frame relay.)

Video Codecs

• H.261. Codec for video at p x 64 kbps (p > 1)

• H.263. Codec for low - bitrate video (< 64 kbps) over the GSTN

Related Standards

• H.320. The original standard for videoconferencing over ISDN networks

• H.324. An extension of H.320 for video conferencing over the GSTN

• T.120. Real-time data and conferencing control

SessionInitiation Protocol (SIP) — A Signaling ProtocolSIP an application - layer control

protocol in charge of establishing and terminating sessions in Internet telephony. These sessions
are not limited to VoIP communications — they also include multimedia conferences and
multimedia distribution.

Similar to HTTP, SIP is a text - based protocol that is different from H.323. It is also a client -
server protocol. A caller (the client) initiates a request, which a server processes and responds
to. There are three types of servers. A proxy server and a redirect sewer forward call requests.
The difference between the two is that the proxy server forwards the requests to the next - hop
server, whereas the redirect server returns the address of the next - hop server to the client, so as
to redirect the call toward the destination.

The third type is a location server, which finds current locations of users. Location servers
usually communicate with the redirect or proxy servers.They may use finger, rwhois,
Lightweight Directory Access Protocol (LDAP), or other multicast - based protocols to determine
a user's address.

SIP can advertise its session using e - mail, news groups, web pages or directories, or Session
Announcement Protocol (SAP) — a multicast protocol.

The methods (commands) for clients to invoke are

• INVITE — invites callee (s) to participate in a call.

• ACK — acknowledges the invitation.
• OPTIONS — inquires about media capabilities without setting up a call.
• CANCEL — terminates the invitation.
 • BYE — terminates a call.
• REGISTER — sends user's location information to a registrar (a SIP server).

FIGURE 4.7: A possible scenario of SIP session initiation

The above figure illustrates a possible scenario when a caller initiates a SIP session:

• Step 1. Caller sends an INVITE to the local Proxy server PI.

• Step 2.The proxy uses its Domain Name Service (DNS) to locate the server for and sends
the request to it.
• Steps 3, 4. is not logged on the server. A request is sent to the nearby location server.
John's current address, is located
• Step 5.Since the server is a redirect server, it returns the address. Ca to the proxy server
PL
• Step 6. Try the next proxy server P2 for john
• Steps 7,8. P2 consults its location server and obtains John's local address, john _ doe.
• Steps 9,10. The next - hop proxy server P3 is contacted, which in turn forwards the
invitation to where the client (callee) is.
• Steps 11-14. John accepts the call at his current location (at work) and the
acknowledgments are returned to the caller.

SIP can also use Session Description Protocol (SDP) to gather information about the callee's
media capabilities.

Session Description Protocol (SDP). As its name suggests, SDP describes multimedia sessions.
As in SIP, SDP descriptions are in textual form. They include the number and types of media
streams (audio, video, whiteboard session, etc.), destination address (unicast or multicast) for
each stream, sending and receiving port numbers, and media formats (payload types). When
initiating a call, the caller includes the SDP information in the INVITE message. The called party
responds and sometimes revises the SDP information, according to its capability.

4.3 Media-On-Demand (Mod)

Media - on - Demand involves many fundamental multimedia network communication issues.
In this section, we will briefly introduce Interactive TV, broadcast schemes for video - on -
demand, and issues of buffer management.

4.3.1 Interactive TV (ITV) and Set - Top Box (STB)

Interactive TV (ITV) is a multimedia system based on the television sets in homes. It can support
a growing number of activities, such as

1. TV (basic, subscription, pay - per - view)

2. Video - on - Demand (VOD)
3. Information services (news, weather, magazines, sports events, etc.)
4. Interactive entertainment (Internet games, etc.)
5. E - commerce (online shopping, stock trading)
6. Access to digital libraries and educational materials

A new development in Digital Video Broadcasting (DVB) is Multimedia Home Platform (DVB
- MHP) which supports all the activities above as well as electronic program guide (EPG) for
television.

The fundamental differences between ITV and conventional cable TV are first, that ITV invites
user interactions; hence the need for two - way traffic - downstream (content provider to user)
and upstream (user to content provider). Second, ITV is rich in information and multimedia
content.

To perform the above functions, a Set - top Box (STB) is required, which generally has the
following components:

Network interface and communication unit ,including tuner and demodulator (to extract the
digital stream from analog channel), security devices, and a communication channel for basic
navigation of WWW and digital libraries as well as services and maintenance

1. Processing unit, including CPU, memory, and a special - purpose operating system for
the STB
2. Audio / video unit, including audio and video (MPEG - 2 and 4) decoders, Digital Signal
Processor (DSP), buffers, and D / A converters
3. Graphics unit,supporting real - time 3D graphics for animation and games
4. Peripheral control unit, controllers for disks, audio and video I / O devices (e.g., digital
video cameras), CD / DVD reader and writer, and so on

4.3.2 General architecture of Set - top Box

 FIGURE 4.8: Broadcast Schemes for Video - on - Demand

Among all possible Media - on - Demand services, the most popular is likely to be subscription
to movies: over high - speed networks, customers can specify the movies they want and the time
they want to view them. The statistics of such services suggest that most of the demand is usually
concentrated on a few (10 to 20) popular movies (e.g., new releases and top - ten movies of the
season). This makes it possible to multicast or broadcast these movies, since a number of clients
can be put into the next group following their request.

An important quality measure of such MOD service is the waiting time (latency). Given the
potentially extremely high bandwidth of fiber - optic networks, it is conceivable that the entire
movie can be fed to the client in a relatively short time if it has access to some high - speed
network. The problem with this approach is the need for an unnecessarily large storage space at
the client side.

4.3.3 Broadcast Schemes for Video-on-Demand

• Staggered Broadcasting – For simplicity, assume all movies are of length L (seconds).
– The available high bandwidth B of the server (measured as the multiple of the playback rate b)
is usually divided up into K logical channels (K ≥ 1).
– Assuming the server broadcasts upto M movies (M ≥ 1), they can be periodically broadcast on
all these channels with the start-time of each movie staggered— Staggered broadcasting.
– If the division of the bandwidth is equal amongst all K logical channels, then the access
time(longest waiting time)for any movie is actually independent of the value of K, i.e.,
δ = (M ·L)/ B
FIGURE 4.9: Staggered Broadcasting with M =8moviesand K =6channels.
4.3.4 Pyramid Broadcasting
1. Movies are divided up into segments of increasing sizes, i.e., Li+1 = α·Li,
where Li is the size(length)of Segment Si and α>1.
2. Segment Si will be periodically broadcast on Channel i. In other words, instead of staggering
the movies on K channels, the segments are now staggered.
3. Each channel is given the same bandwidth, and the larger segments are broadcast less
frequently.
4. Since the available bandwidth is assumed to be significantly larger than the movie playback
rate b (i.e. B>>1), it is argued that the client can be playing a smaller Segment Si and
simultaneously receiving a larger Segment Si+1.
5. To guarantee a continuous playback, the necessary condition is:
playback time(Si) ≥ access time(Si+1)
6.The playback time (Si) =Li. Given the bandwidth allocated to each channel is B/K, access time
(Si+1)=(L i+1)M /(B/K) = (α·Li·M )/(B/K) , which yields

7. The access time for Pyramid broadcasting is determined by the size of S1.Bydefault,we set
α = B M·K to yield the shortest access time.
8. The access time drops exponentially with the increase in the total bandwidth B, because α
can be increased linearly.

4.3.5 Skyscraper Broadcasting

1. A main drawback of the above Pyramid Broadcasting scheme is the need for a large storage
space on the client side because thelasttwosegmentsaretypically75-80% of the movie size.
2. Instead of using a geometric series, Skyscraper broadcasting uses
{1,2,2,5,5,12,12,25,25,52,52,...} as the series of segment sizes to alleviate the demand on
a large buffer.

FIGURE 4.10: Skyscraper broadcasting with seven segments

3. As shown in Fig4.12, two clients who made a request at time intervals (1,2) and (16,17),
respectively, have the irrespective transmission schedules. At any given moment, no more
than two segments need to be received.

4.3.6 Harmonic Broadcasting

1. Adopts a different strategy in which the size of all segments remains constant whereas
the bandwidth of channel i is Bi = b/I, where b is the movie’s play back rate.
2. The total bandwidth allocated for delivering the movie is thus

where K is the total number of segments, and HK = PK i=1 1 I is the Harmonic number of
K.
 FIGURE 4.11: Harmonic Broadcasting.
1. As Fig.16.14shows: after requesting the movie, the client will be allowed to download and
play the first occurrence of segment S1 from Channel1. Meanwhile, it will download all
other segments from their respective channels.
2. The advantage of Harmonic broad casting is that the Harmonic number grows slowly with
K.
3. For example, when K =30, HK ≈ 4.Hence, the demand on the total bandwidth (inthiscase4·b)
is modest.
4. It also yields small segments—only 4minutes (120/30) each in length. Hence, the access
time for Harmonic broadcasting is generally shorter than pyramid broadcasting.

Pagoda Broadcasting
1. Harmonic broadcasting uses a large number of low-bandwidth streams, while Pyramid
broadcasting schemes use a small number of high-bandwidth streams.
2. Harmonic broadcasting generally requires less bandwidths than Pyramid broadcasting.
However, it is hard to manage a large number of independent datastreams using Harmonic
broadcasting.
3. Paris, Carter, and Long presented Pagoda Broadcasting, a frequency broadcasting scheme
that tries to combine the advantages of Harmonic and Pyramid schemes.

FIGURE 4.12: First three channel-segment maps of Pagoda Broadcasting.

 4. Partition seach video into n fixed-size segments of duration T = L/n, where T is defined
as a time slot. Then, it broadcasts these segments at the consumption bandwidth b but
with different periods.
Stream Merging
1. More adaptive to dynamic user interactions. It achieves this by dynamically combining
multicast sessions.
2. Makes the assumption that the client’s receiving bandwidth is higher than the video playback
rate.
3. The server will deliver a video stream as soon as it receives the request from a client.
4. Meanwhile, the client is also given access to a second stream of the same video, which was
initiated earlier by another client.

FIGURE 4.13: Stream merging.

5. As shown in Fig.16.16, the “first stream” B starts at time t =2. The solid line indicates
the playback rate, and the dashed line indicates the receiving bandwidth which is twice
of the playback rate. The client is allowed to prefetch from an earlier (“second”) stream
A which was launched at t =0. At t =4,the stream B joins A.
6. A variation of Stream merging is Piggybacking, in which the playback rate of the streams
are slightly and dynamically adjustedsoastoenablemerging(piggybacking)ofthestreams.

• TocopewiththeVBRandnetworkloadfluctuation,buffers
areusuallyemployedatbothsenderandreceiverends:
– A PrefetchBuffer isintroducedattheclientside.Ifthesizeofframe t is d(t),thebuffersizeis
B,andthenumberofdatabytesreceived sofar(atplaytimeforframe t)isA( t ),thenforall t ∈
1,2,...,N,itisrequiredthat
t X i=1
d(i) ≤ A(t) ≤
t−1 X i=1
d(i)+B. (16.9)
– When A(t) < Pt i=1 d(i),wehaveinadequatenetworkthroughput, andhencebuffer underflow (or
starvation),whereaswhen A(t) > Pt−1 i=1 d(i)+B,wehaveexcessivenetworkthroughputandbuffer
overflow. –
Bothareharmfultosmoothandcontinuousplayback.Inbufferunderflowthereisnoavailabledatatopla
y,andinbufferoverflowmedia packetsmustbedropped.