Instructor: Prof. Hall Conducted by: Wayde Anwar Vikas Choong Nathan Nadia

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) -> IP network-> 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 won’t 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@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: doesn’t 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 (hardware:codec) • 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 !