CS计算机代考程序代写 Media Transport in Packet Networks

Media Transport in Packet Networks
Anjali Agarwal

Why Not Use TCP?
 Four problems
» No need for 100% reliability
» Slow start
» Retransmissiondelay
» Window backoff
» N participants -> N*N connections » So use UDP and IP multicast
Anjali Agarwal 2

Need for RTP
 Loss, out of order: sequence number
 Loss, jitter: timestamp
 Source/payload identification
 Rate control: QoS feedback
 RTP provides functions to support these requirements for many real-time applications
Anjali Agarwal 3

RTP: de facto standard
 End-to-end transport of real-time data, such as audio and video; and data for non-real-time applications
 Does not guarantee QoS
 Does not address resource reservation along the path of a connection
 Requirestheuseofsignalingprotocoltosetuptheconnectionand
negotiate media format to be used
 RTPisenhancedwithRTCPwhichispartoftheRTPspecification
» RTCP provides for end-to-end monitoring of data delivery and QoS
 Independent of the underlying transport and network layers
» most commonly used on UDP
RTP assigned an even UDP port number RTCP assigned the next higher UDP port (odd)
 Supportsmultipledestinationsifnetworksupportsmulticastdistribution Anjali Agarwal 4

Anjali Agarwal 5

Packet based delivery – basic issues
 Store and forward handling in routers – delay
» IP switching (hardware technology) to reduce intermediate
packet delays
 High protocol overhead (RTP over UDP over IP over ATM) – extra bandwidth requirement
 To achieve bandwidth savings –
» Header compression often prescribed and used
» statistical multiplexing – mixing of voice and data packets
 Problem – not backward compatible with existing routers » new router designs
Anjali Agarwal 6

Packet based delivery – basic issues
Uncompressed RTP/UDP/IP header = 12+8+20 = 40 bytes
Encapsulation overhead for ATM (RFC1483) = 8 bytes
Payload = N bytes per packet
» this represents an entire ATM cell of 48 bytes + an ATM header of 5 bytes before first byte of payload is transmitted
Minimum of 2 ATM cells is required for a single voice sample
Using header compression (RFC2809) 40 bytes is reduced to 2 bytes
Anjali Agarwal 7

Voice over RTP bandwidth calculations
Payload format
Nominal rate
Packet rate (ms)
Payload size (bytes)
Required BW (Kbps) uncompressed compressed
G.711
64 Kbps
20
160
80
64.8
G.711
10
80
96
65.6
G.729
8 Kbps
20
20
24
8.8
G.729
10
10
40
9.6
 Packet rate is the frequency with which packets are formed and transmitted – either 10 ms or 20 ms for most applications
 Bits per 20 ms packetization interval for G.711 over RTP/UDP/IP/Encaps/AAL5 = minimum 5 ATM cells = 53*5 bytes = 2120 bits
Anjali Agarwal 8

Compressed packet headers –
 additional computational requirements in
intermediate routing nodes
 major issue with user multiplexing and stream mixing at intermediate points
 header expansion and interpretation at intermediate nodes can be lengthy process – adds to end-to-end delay
Anjali Agarwal 9

RTP packet
Anjali Agarwal 10

RTP packet header
Version (V, 2 bits)
 Padding (P, 1 bit) – for encryption with fixed block sizes
 if set, last byte of the padding contains a count of how many padding bytes should be ignored
 Extension (X, 1 bit) –
 if set, the fixed header is followed by exactly one header extension (2 bytes) to pass control information not to be interpreted by intermediate nodes
 CSRC count (CC, 4 bits) – for mixers
 number of contributing sources to this packet  if only one SSRC in the stream, CC = 0
Anjali Agarwal 11

RTP packet header
Marker (M, 1 bit) – to mark frame boundaries
 signifies the beginning/end of a talk spurt (to begin playout of
comfort noise), or end of a video frame.
 Payload Type (PT, 7 bits) – format of RTP payload
(e.g. G723)
 once a session is set up, a sender cannot use different RTP payloads during the session
 Sequence Number (16 bits) – +1 for each packet
 used by receiver to detect packet loss and to restore packet sequence  packet reordering very hard to do – costs in voice/video quality
Anjali Agarwal 12

RTP packet header
Timestamp (32 bits) – random starting value
 increments by one for each sampling period for fixed-rate audio
 If an audio application reads blocks covering 160 sampling periods from the input device, the timestamp would be increased by 160 for each such block
 SSRC (32 bits) – identifies synchronization source (sender)  value chosen randomly – no two senders have same SSRC identifier  collisions resolved by simple mechanisms in RTP
 CSRC list (0 to 15 items, 32 bits each) –
 identifies contributing sources for payload contained in this packet
 used for correct source identification when payloads played out at endpoint
Anjali Agarwal 13

Mixers and Translators
Anjali Agarwal 14

Anjali Agarwal 15

Anjali Agarwal 16

IMPLEMENTATIONS OF RTP OVER THE INTERNET
“Internet telephones” (usually for PCs) available using proprietary audio coding and protocols, meant for point-to-point connections:
 Speak Freely for Unix and Windows  Vocaltec Internet Phone)
 SoftFone by SilverSoft
 Digiphone
 Quarterdeck
 InternetTelephoneCompany
 Telescape Intercom by Telescape  IBM Internet Connection Phone
 CuSeeMe (for Windows PC and the Macintosh)
IRIS
 Lucent 4111 Multifunctional DCP
Voice Terminal
 Audio/video directly over ATM: Nemesys
 FreeVue audio and video
 NVAT
 Ericsson LAN Phone
 RealAudio (Microsoft Windows only)  AudioSoft
 VDO
Anjali Agarwal 17

Real Time Control Protocol (RTCP)

 Based on periodic transmission of control packets to all
to convey end-to-end information about the quality of the session to each participant
» like packet delay, jitter, packets received and lost are valuable to access network health in real-time
participants
 RTP and RTCP may or may not be routed on the same end- to-end path
Anjali Agarwal 18

RTCP packet format
 SR: Sender Report
» for transmission and reception statistics from active sender
participants
 RR: Receiver Report
» for reception statistics from not active senders
ietf-avt-rtp-new-03.txt (work in progress)
» suggests 5%of session bandwidth be allocated for RTCP packets
 1.25% go to senders
 3.75% be allocated to receivers
Anjali Agarwal 19

Anjali Agarwal 20

RTCP Sender Report
 SSRC of sender: identifies sending source of SR
 NTPtimestamp:whenreportwassend
 RTPtimestamp:correspondingRTPtime
 Sender’s packet count: total RTP packets sent
 Sender’soctetcount:totaloctetssent
 rc:numberofreceptionreportcounts(max32)forwhichstatisticsare
included in the packet
 FL:fractionofpacketslostsincelastSRwassend
 Cumulative packets lost: since beginning of session
 HighestsequencenumberreceivedfromSSRCn
 interarrival jitter as measured at the receiver
 LSR:timelastSRheard
 DLSR: delay since last SR
Anjali Agarwal 21

RTCP Receiver Report
 Conveys identical information as SR except sender information
 An endpoint can send RR or SR but SR contain overall packet and byte counts not reported in RR.
Anjali Agarwal 22

Anjali Agarwal 23

 SDES: Source DEScription
» binds SSRC in RTP with actual user identification  user’s name, email address, login ID
 optional items as telephone #, user location
» send at beginning of the session to explicitly identify each participant
 BYE: ends user participation in a call
» tells all participants that sending user is departing » should contain the reason for statistics
 APP: application specific RTCP packet » none yet (work in progress)
RTCP packet format
Anjali Agarwal 24

RTCP SDES packets
 binds an SSRC to sender’s real identification
 up to 32 participants identified
 SDES items contain item id, length of item, and item itself
 Only 8 SDES items currently proposed
Anjali Agarwal 25

Anjali Agarwal 26

Anjali Agarwal 27

Bye packet
Anjali Agarwal 28

RTCP packet
Anjali Agarwal 29

Anjali Agarwal 30