Sunil-RTP by wuyunyi


multimedia protocols for the Internet

  Center for Software Development
         CSD, BITS - Pilani

           CopyRight: IPv6@BITS
           1. The RTP Protocol
•   1.1 Overview
•   1.2 RTP generalities
•   1.3 RTP Use Scenarios
•   1.4 RTP Header Format
•   1.5 Mixers and Translators
•   1.6 RTP: Potential Problems

                 CopyRight: IPv6@BITS
             1.1 RTP Overview
• Real-Time Protocol (RTP)
  – a protocol for real-time applications like video, etc.
  – does not define any QoS mechanism for real-time
• Applications typically run RTP on top of
  UDP to make use of its multiplexing and
  checksum services

                  CopyRight: IPv6@BITS
           1.2 RTP generalities
• carry data that has real-time properties
   – Simple Multicast Audio Conference
   – Audio and Video Conference
• Scalable: unicast, multicast, from 2 to 
• Timing
   – intra-media synchronization: remove jitter with
     playout buffers
   – inter-media synchronization: lip - synchro between

                 CopyRight: IPv6@BITS
        1.3 RTP Use Scenarios
• Simple Multicast Audio Conference
  – Each participant uses two ports. One for audio data
    and the other for control (RTCP) packets
  – Each participant sends audio data in small chunks of
    say 20 mS duration
  – A RTP header is added which contains the timing
    field that ensures that the chunks of data are
    continuously played for every 20mS

                CopyRight: IPv6@BITS
        1.3 RTP Use Scenarios
• Audio and Video Conference
  – Both audio and video are transmitted as two separate
    RTP sessions.
  – separate RTP and RTCP packets are transmitted for
    each medium using two UDP port pairs and
    multicast addresses.
  – no direct coupling at the RTP level between the
    audio and video sessions

                  CopyRight: IPv6@BITS
         1.4 RTP Header Format
• Sequence number field
   – incremented for each RTP packet

• Synchronization SouRCe (SSRC) field
   – uniquely identifies the source in the session
   – chosen randomly

• Contributing SouRCe (CSRC) and CC fields
   – used by a mixer to identify the contributing sources
   – size of the list given by the CSRC Count (CC) field

                      CopyRight: IPv6@BITS
                  1.5 Mixers

• Mixers
  – Helps in resynchronizing the incoming audio packets
    and forward it to the low speed link.
  – Also combines several flows in a single new one
  – appears as a new source

                 CopyRight: IPv6@BITS
                     1.5 Mixers
• Mixers
  – a mixer may change the data format (coding) and
    combine the streams in any manner
  – example: video mixer

 end system 1
      from ES1: SSRC=6
                          mixer   from M: SSRC=52
                                                      end system 3
      from ES2: SSRC=23
                                  CSRC list={6, 23}
 end system 2

                    CopyRight: IPv6@BITS
               1.5 Translators
• Two translators are installed, on either side of
  the firewall, with the outside one tunneling all
  multicast packets received through a secure
  connection to the translator inside the firewall.

• e.g. protocol translation, firewall

                  CopyRight: IPv6@BITS
                      1.5 Translators
 • data may pass through the translator intact or
   may be encoded differently
 • the identity of individual flows remains intact!
 • example: going through a firewall
end system 1                      from ES1: SSRC=6
   from ES1: SSRC=6               from ES2: SSRC=23
                       transl.1                       transl.2
   from ES2: SSRC=23              authorized tunnel
end system 2                          firewall        from ES1: SSRC=6
                                                      from ES2: SSRC=23

                         CopyRight: IPv6@BITS
    1.6 RTP: Potential Problems

• Potential problems over standard Internet
  packets may be
  – Lost
  – Reordered
  – fragmented by IP if size > std. Max size

                  CopyRight: IPv6@BITS
          2. The RTCP Protocol

•   2.1 RTCP generalities
•   2.2 Distribution of RTCP Packets
•   2.3 Scalability
•   2.4 RTCP Packet Format

                  CopyRight: IPv6@BITS
           2.1 RTCP generalities
• periodic transmission of control packets
• Functions:
   – feedback on the quality of data distribution
   – Permits everybody evaluate the number of participants
   – persistant transport-level canonical name for a source,
      • usually: user@host
      • will not change, even if SSRC does!
      • provides binding across multiple media tools for a single user

                        CopyRight: IPv6@BITS
2.2 Distribution of RTCP Packets
• Distribution
  – use same distribution mechanisms as data packets
  – Underlying protocol should provide multiplexing
    for data and control packets (in this case UDP)
  – multiple RTCP packets can be concatenated by
        compound RTCP packet

                 CopyRight: IPv6@BITS
                 2.3 Scalability
• scalability with session size

   – RTCP traffic should not exceed 5% of total session
       requires an evaluation of number of participants
       RTCP tx interval = f(number of participants)

   – let new receivers quickly know CNAME of sources!

                   CopyRight: IPv6@BITS
    2.4 RTCP Packet Format

SR: Sender report, for transmission and reception
 statistics from participants that are active senders
RR: Receiver report, for reception statistics from
 participants that are not active senders
SDES: Source description items, including CNAME
BYE: Indicates end of participation
APP: Application-specific functions

                CopyRight: IPv6@BITS
1. Request for Comments: 3550
   H. Schulzrinne, Columbia University;
   S. Casner Track Packet Designer.
   FrederickBlue Coat Systems Inc.
   Jacobson, Packet Design, July 2003

2. Request for Comments: 1889

                CopyRight: IPv6@BITS

CopyRight: IPv6@BITS

To top