Instructor: Prof. Hall

1
Chapter 29
Applications Voice and Video over IP (RTP)
Instructor Prof. Hall Conducted
by Wayde Anwar Vikas Choong Nathan Nadia
2
29.1 Introduction

• This chapter focuses on real-time audio/video
  transfer over IP networks.
• It examines the question of how IP can be used to
  provide commercial telephone service.
• It examines the question of how routers in an IP
  network can guarantee sufficient service to
  provide HiQ A/V reproduction.

3
29.2 Audio Clips and Encoding Standards

• Simplest digitizing A/D (encoding) -gt IP
  network-gt D/A (decoding)
• OK for audio clips, not for interactive b/c of
  delay introduced
• HiQ codec are available (Amplitude overtime to
  sequence of digits, reconstruct from the digits
  to waveform).
• Standards based on the tradeoffs b/w quality and
  reproduction and size of digital representation.

4
29.2 Audio Clips and Encoding Standards(Continued)

• E.g. PCM for phone line (huge file production)
• Three ways to reduce the size
• Fewer samples Low quality
• Fewer bits Low quality
• Compression Delay(require fast CPU) good when
  delay is not important.

Produce data at 2.2 kbps
5
29.3 Audio and Video Transmission and Reproduction

• AV application are real-time timely transmission
  (missing data is skipped).
• How can a network guarantee that the stream is
  delivered at exactly the same rate that the
  sender used?
• Telephone system way the entire system is
  engineered(digital circuits included) to deliver
  output at the same rate of the input even for
  multiple paths.

6
29.3 Audio and Video Transmission and
Reproduction(cont)

• IP network is not isochronous for the delay
  introduced vary delay is called jitter.
• Additional protocol is needed in addition to IP
• Each packet must have timestamp to tell the
  sender when to play back.
• This is important b/c it tells the receiver to
  pause when a packet is lost or sender stops
  encoding.

7
29.4 Jitter and Playback Delay

• How can a receiver recreate a signal accurately
  if the network introduces a jitter?
• Playback buffer (similar to queue)
• How does it work?
• The receiver introduces a delay until the buffer
  is filled with incoming data (Threshold-playback
  point) figure 29.1- (K) is the unit of time of
  data to be played.
• The receiver plays K time units.
• If no jitter , datagrams continue to arrive at
  the same rate, so the buffer is filled with K
  time units of un-played data

8
29.4 Jitter and Playback Delay(Cont)

• If small delay, playback wont be affected, the
  buffer decreases as data are extracted, playback
  continues for K units, once the delayed datagrams
  arrive buffer will be refilled.
• If a datagram is lost, buffer will be empty,
  output pauses for time corresponding for the
  missing data.
• K is small needed buffer will be used before
  delayed data arrive.
• K is too large immunity to jitter with
  noticeable delay (in addition to NW delay) to
  user.
• Playback is still used despite disadvantages.

9
29.5 Real-Time Transport Protocol (RTP)

• It does not provide timely transmission. Timely
  manner depends on the underlying system.
• It provides
• Sequence Number
• Timestamp
• RTP does not distinguish b/w types of data
  therefore, it does not enforce uniform
  interpretation of semantics.

For the receiver to control playback.
10
29.5 Real-Time Transport Protocol (RTP) (Cont)

• RTP header provides needed information for
  interpretation by the receiver
• 2 bit version (current 2)
• 16 bit SEQUENCE NUM first one is randomly
  chosen.
• X-bit is used to identify if the application
  defines optional header extension b/w RTP header
  and pay load.
• 7 bit PTYPE determines the interpretation of the
  most remaining header field (Pay Load Type).

11
29.5 Real-Time Transport Protocol (RTP) (Cont)

• P-bit specify whether padding is in effect to the
  pay load. (Encryption How data is allocated in
  blocks).
• M-bit used by the application (Marking points
  e.g. beginning of video stream)
• 32-bit TIMESTAMP affected by the type at which
  first octet is digitized.

12
29.6 Streams, Mixing, and Multicasting

• Key Part to RTP is its support for translation or
  mixing.
• Translation changing the encoding of a stream at
  an intermediate station.
• Mixing receiving streams of data from multiple
  sources, combining them into a single stream, and
  sending the results.
• Mixers are important to service multiple streams
  in conferencing.

13
29.6 Streams, Mixing, and Multicasting(Cont.)

• The field SYNCHRONIZATION SOURCE IDENTIFIER
  specifies. Each source must choose a unique
  identifier. If mixer is enabled, the mixer will
  be the source of the new stream.
• The original source is not lost b/c mixer uses
  CONTRIBUTING SOURCE ID to identify the actual
  stream source.
• CC-field gives the number of contributing sources.

14
29.6 Streams, Mixing, and Multicasting(Cont.)

• RTP works with IP multicasting and mixing
  especially in multicast environment.
• For example, in teleconference situation, unicast
  is cumbersome however, multicasting will allow
  multi-users to communicate both ways at the same
  time. Mixers make this possible by reading
  several inputs resulting in fewer datagrams.

15
29.7 RTP Encapsulation

• RTP is a transport-level protocol working on the
  top of UDP.
• This means that it needs to be encapsulated in
  UDP before the final encapsulation in IP
  datagram.
• RTP does not have a reserved port number. Port is
  allocated for each session, and remote app must
  inform about port number. RTP prefer even numbers.

16
29.8 RTP Control Protocol

• So far, Real-Time transmission has been explained
  as a protocol allowing reproduction of A/V data.
• Monitoring the underlying network is as important
  as the protocol itself during each session, and
  providing out of band com b/w endpoints.
  (Adaptive applications).
• An application may adjust the buffer size, or
  choose lower band width due to NW cong.

17
29.8 RTCP (Cont.)

• Out of Band can be used to send information in
  parallel with real time like caption.
• RTP control protocol (RTCP) provides the needed
  control functionality.
• RTCP allows senders and receivers to transmit a
  series of reports one to another that contain
  additional info about data transferred in
  addition to NW performance.
• RTCP is encapsulated in UDP using a port number
  that is greater than RTP port number.

18
29.9 RTCP Operation

• Uses 5 basic message type
• 200 - Sender Report - provides absolute timestamp
• Absolute timestamp is essential to synchronize
  multiple streams
• Since RTP require separate stream for each media
  , transmission of video/audio require 2 streams
• 201 - Receiver Report - Inform source about
  conditions of reception
• allow participating receivers senders in a
  session to learn about reception conditions of
  other receivers

19
29.9 RTCP Operation

• allow receivers to adapt their rate of reporting
  to avoid using excessive bandwidth overwhelming
  the sender
• 202 - Source Desc. Message - general info about
  user (owns/ control source)
• Each message contain 1 section for each outgoing
  RTP stream
• 203 - Bye Message - Shutting down a stream
• 204 - Application Specific Message - extend basic
  facility to allow application to define message
  type

20
29.10 IP telephony Signaling

• Real-time transmission use of IP as the
  foundation for telephone service
• Researches are investigation 3 components to
  replace isochronous systems
• RTP is needed to transfer a digitized signal
  across an IP internet correctly
• Mechanism is needed to establish and terminate
  telephone calls
• Researches are exploring ways an IP internet can
  function like an isochronous network

21
29.10 IP telephony Signaling

• Telephone industry use Signaling process of
  establishing a telephone call
• Public Switched Telephone Network (PSTN) uses
  Signaling System 7 (SS7)
• performs call routing before any audio is sent
• handles call forwarding and error conditions

22
29.10 IP telephony Signaling

• Signaling functionality must be available before
  IP can be used to make calls
• IP telephony must be also compatible with extant
  telephone standards
• Must be possible for IP telephony system to
  interoperate with the conventional phone system
  at all levels.

23
29.10 IP telephony Signaling

• The general approach to interoperability uses a
  gateway between IP conventional phone system
• Standards for IP Telephony
• ITU has defined a suite or protocol known as
  H.323
• IETF has proposed a signaling protocols know as
  SIP

24
29.10.1 H.323 Standards

• Originally created to allow the transmission of
  voice over local area
• Then it was extended to allow transmission of
  voice over IP internets
• Specifies how multiple protocols can be combined
  to form functional IP telephony
• Defines gateways gatekeepers
• provide a contact point for telephones using IP.
• Each IP Telephone must register with a
  gatekeeper

25
29.10.1 H.323 Standards

• H.323 relies on 4 major protocols
• H.225.0 Signaling used to establish a call
• H.224 Control and feedback during the call
• RTP Real-time data transfer
• T.120 Exchange of data associated with a call
• Fig 29.5 illustrates relationship among the H.323
  protocols

26
29.10.2 Session Initiation Protocol (SIP)

• Covers only signaling, doesn't supply all of
  H.323 functionality
• Uses client-server interaction, with servers
  being divided into 2 types
• user agent server runs in a SIP telephone
• assigned an identifier user_at_site
• intermediate server between 2 SIP telephone
• handles call set up and call forwarding

27
29.10.2 Session Initiation Protocol (SIP)

• SIP relies on Session Description Protocols SDP
  (companion protocol)
• SDP important in conference call
• participants join and leave dynamically
• SDP specifies media encoding, protocols number
  and multicast address

28
29.11 Resource Reservation/Quality of Service

• Quality of Service (QoS) refers to statistical
  performance guarantees
• regarding loss, delay, jitter and throughput
• An isochronous network that meet strict
  perfomacnce bounds provide QoS
• Packet switched network doesn't provide QoS
• Is QoS needed for real-time transfer of voice
  video over IP?

29
29.11 Resource Reservation/Quality of Service

• Internet send audio but operates without QoS
• ATM, derived from telephone system model, provide
  QoS guarantees
• IETF adopted a differentiated services approach
• divide traffic into separate QoS classes
• sacrifice fine grain control for less complex
  forwarding

30
29.12 QoS Utilization Capacity

• Central issue is utilization
• a network with 1 utilization doesnt need QoS
• a network with 1o1 utilization will fail under
  any QoS
• Proponent who argue for QoS assert that QoS
  mechanism is important because
• by dividing the existing resources among more
  users, system become more fair

31
29.12 QoS Utilization Capacity

• by shaping traffic, the network run at higher
  utilization without danger of collapse
• As long as rapid increases in capacity continues,
  QoS represent cause unnecessary overhead
• When demand rises more rapidly than capacity, it
  becomes an economic issue

32
29.13 RSVP

• How can IP network provide QoS?
• IETF produced 2 protocols RSVP COPS
• QoS cannot be added at the application layer to
  IP basic infrastructure must change
• Infrastructure must change routers must agree to
  reserve resources
• Endpoints must send a request to spefiicy
  resources needed before data is sent
• As datagrams traverse the flow, routers need to
  monitor (traffic policing) and control traffic
  forwarding

33
29.13 RSVP

• Control of queuing is needed
• router must implement a queuing policy that meets
  guaranteed bounds on delay
• router must smooth packet burst (traffic shaping)
• RSVP is not a routing protocols operates before
  any data is sent and handles reservations request
  and replies.
• RSVP is unidirectional (simplex) if application
  needs QoS in two directions, each point must use
  RSVP to request a separate flow

34
29.14 COPS

• When an RSVP arrivers a router must evaluate
• feasibility a local decision
• policies requires global cooperation
• IETF architecture uses 2-level model
• when router receiver RSVP request, it becomes a
  client which consult server Policy Decision
  Point (PDP) to determine whether request meets
  policy constraints
• if PDP approves a request, router must operate as
  Policy Point Point (PEP)to ensure traffic does
  not exceed the approved policy
• COPS protocol define the client-server
  interaction between a router and a PDP

35
29.14 COPS

• Although COPS defines it own message header, the
  underlying format shares many details with RSVP
• When a router receives an RSVP request
• extract items related to policy
• place them in a COPS message
• send the result to PDP

36
Summary

• Audio data can be encoded in digital form
  (hardwarecodec)
• Pulse Code Modulation (PCM) produce digital
  values at 64 Kbps
• RTP is used to transfer real-time data across an
  IP internet. Each message contain
• sequence number
• a media timestamp

37
Summary

• RTCP is used to supply information about sources
  allow mixer to combine several streams
• Debate continues where Q0S guarantees is needed
  to provide real-time
• Endpoints use RSVP to request a flow with
  specific QoS intermediate routers either approve
  or deny the request
• When RSVP request arrives, router use COPS to
  contact PDP and verify that request meets policy
  constraints

38
Thanks !