Part 2: Making the Best of Best-Effort IT 424- Networks2 Dr. Hala Mokhtar Lecture 10 Chapter 4:Multimedia Networks (ch. 7 in book) Part 2: Making the Best of Best-Effort Ack.: Slides are adapted from the slides of the book: “Computer Networking” – J. Kurose, K. Ross

Overview Lecture 10 Voice over IP (VoIP) Recovery From Packet Loss Content Distribution Networks Lecture 10 Real-Time Protocol (RTP) SIP: Session Initiation Protocol

Learning Outcomes Lecture 10 To describe the characteristics of VoIP technology 2 To explain how delay jitter can affect VoIP quality and describe how to mitigate its effect To describe the RTP protocol and explain its rol 5 To differentiate between the different methods for packet loss recovery 3 Lecture 10 To explain the operation of the SIP protocol 6 To explain the role of Content Distribution Networks (CDN) 4

Voice-over-IP (VoIP) Lecture 10 Voice-over-IP (VoIP) Recovery From Packet Loss Content Distribution Networks Real-Time Protocol (RTP) SIP: Session Initiation Protocol Lecture 10 Voice-over-IP (VoIP)

Voice-over-IP (VoIP) - Introduction VoIP could be applied to almost any voice communications requirement, ranging from a simple inter-office intercom to complex multi-point teleconferencing/shared screen environments .

Voice-over-IP - Requirements VoIP Characteristics & Requirements Voice-over-IP - Requirements VoIP end-end-delay requirement: needed to maintain “conversational” aspect Higher delays noticeable, impair interactivity < 150 msec: good > 400 msec bad Includes application-level (packetization,playout), network delays Session initialization: how does callee advertise IP address, port number, encoding algorithms? Value-added services: call forwarding, screening, recording

VoIP - Characteristics Speaker’s audio: alternating talk spurts, silent periods. 64 kbps during talk spurt Packets generated only during talk spurts 20 msec chunks at 8 kbytes/sec: 160 bytes of data Application-layer header added to each chunk Chunk+header encapsulated into UDP or TCP segment (typically UDP if no firewalls) Application sends segment into socket every 20 msec during talkspurt

Removing Jitter At The Receiver For VoIP VoIP - Requirements Removing Jitter At The Receiver For VoIP The receiver should provide synchronous playout of voice/video chunks in the presence of random network jitter delay Sequence numbers: Prefacing each chunk with a sequence number that is incremented by the sender Time stamp: The sender stamps each chunk with the time at which the chunk was generated Delaying playout of chunks at the receiver

VoIP: Packet Loss, Delay VoIP - Requirements VoIP: Packet Loss, Delay Network loss: IP datagram lost due to network congestion (router buffer overflow) Delay loss: IP datagram arrives too late for playout at receiver Delays: processing, queueing in network; end-system (sender, receiver) delays Typical maximum tolerable delay: 400 ms Loss tolerance: depending on voice encoding, loss concealment, packet loss rates between 1% and 10% can be tolerated

Recovery From Packet Loss Voice over IP (VoIP) Recovery From Packet Loss Content Distribution Networks Real-Time Protocol (RTP) Lecture 10 SIP: Session Initiation Protocol

Recovery From Packet Loss (1) Challenge: recover from packet loss given small tolerable delay between original transmission and playout Each ACK/NAK takes ~ one RTT Alternative: forward error correction (FEC) Send enough redundant bits to allow recovery without retransmission Simple FEC For every group of n chunks, create redundant chunk by exclusive or-ing n original chunks Send n+1 chunks, increasing bandwidth by factor 1/n Can reconstruct original n chunks if at most one lost chunk from n+1 chunks, with playout delay

Recovery From Packet Loss (2) Another FEC scheme: “Piggyback lower quality stream” Send lower resolution audio stream as redundant information E.G., Nominal stream PCM at 64 kbps and redundant stream GSM at 13 kbps Non-consecutive loss: receiver can conceal loss

Recovery From Packet Loss (3) Interleaving to conceal loss: Audio chunks divided into smaller units, e.g. Four 5 msec units per 20 msec audio chunk Packet contains small units from different chunks If packet lost, still have most of every original chunk No redundancy overhead, but increases playout delay

Content Distribution Networks Voice over IP (VoIP) Recovery From Packet Loss Content Distribution Networks Real-Time Protocol (RTP) Lecture 10 SIP: Session Initiation Protocol

Content Distribution Networks (CDNs) origin server in North America Content replication Challenging to stream large files (e.g., Video) from single origin server in real time Solution: replicate content at hundreds of servers throughout internet Content downloaded to CDN servers ahead of time Placing content “close” to user avoids impairments (loss, delay) of sending content over long paths CDN server typically in edge/access network CDN distribution node CDN server in S. America CDN server in Asia CDN server in Europe

Summary: Internet Multimedia: bag of tricks Use UDP to avoid TCP congestion control (delays) for time-sensitive traffic Client-side playout delay: to compensate for delay & delay jitter Server side matches stream bandwidth to available client-to-server path bandwidth Chose among pre-encoded stream rates Dynamic server encoding rate Error recovery (on top of udp) FEC, interleaving, error concealment Retransmissions, time permitting CDN: bring content closer to clients

Real-Time Protocol (RTP) Voice over IP (VoIP) Recovery From Packet Loss Content Distribution Networks Real-Time Protocol (RTP) Lecture 10 SIP: Session Initiation Protocol

Real-Time Protocol (RTP) RTP specifies packet structure for packets carrying audio, video data RFC 3550 RTP packet provides Payload type identification Packet sequence numbering Time stamping RTP runs in end systems RTP packets encapsulated in UDP segments Interoperability: if two VoIP applications run RTP, they may be able to work together

Real-Time Protocol (RTP) RTP Runs on Top of UDP RTP libraries provide transport-layer interface that extends UDP: Port numbers, IP addresses Payload type identification Packet sequence numbering Time-stamping

RTP Example Consider sending 64 kbps PCM encoded voice over RTP. Real-Time Protocol (RTP) RTP Example Consider sending 64 kbps PCM encoded voice over RTP. Application collects encoded data in chunks, e.g., Every 20 msec = 160 bytes in a chunk. Audio chunk + RTP header form RTP packet, which is encapsulated in UDP segment RTP header indicates type of audio encoding in each packet sender can change encoding during conference. RTP header also contains sequence numbers, timestamps

RTP and QoS RTP and QoS RTP does not provide any mechanism to ensure timely data delivery or other QoS guarantees RTP encapsulation only seen at end systems (not by intermediate routers) Routers provide best-effort service, making no special effort to ensure that RTP packets arrive at destination in timely matter RTP header is normally 12 bytes

RTP and QoS RTP Header Payload Type (7 bits): Indicates type of encoding currently being used. If sender changes encoding in middle of conference, sender informs receiver via payload type field. Payload type 0: PCM , 64 kbps Payload type 3, GSM, 13 kbps Payload type 7, LPC (Linear Predictive Coding), 2.4 kbps Payload type 26, Motion JPEG Payload type 31. H.261 Payload type 33, MPEG2 video

RTP and QoS RTP Header (cont.) Sequence Number (16 bits): Increments by one for each RTP packet sent, and may be used to detect packet loss and to restore packet sequence. Timestamp field (32 bits long): sampling instant of first byte in this RTP data packet SSRC field (32 bits long): identifies source of the RTP stream. Each stream in RTP session should have distinct SSRC.

Real-Time Control Protocol (RTCP) Works in conjunction with RTP Each participant in RTP session periodically sends RTCP control packets to all other participants Each RTCP packet contains sender and/or receiver reports Report statistics useful to application: # packets sent, # packets lost, interarrival jitter Feedback used to control performance Sender may modify its transmissions based on feedback

RTCP: Multiple Multicast Senders Real-Time Control Protocol (RTCP) RTCP: Multiple Multicast Senders sender RTCP RTP RTCP RTCP receivers Each RTP session: typically a single multicast address; all RTP /RTCP packets belonging to session use multicast address RTP, RTCP packets distinguished from each other via distinct port numbers To limit traffic, each participant reduces RTCP traffic as number of conference participants increases

RTCP Packets Receiver report packets: Real-Time Control Protocol (RTCP) - Packets RTCP Packets Receiver report packets: Fraction of packets lost, last sequence number, average interarrival jitter Sender report packets: SSRC of RTP stream, current time, number of packets sent, number of bytes sent Source description packets: E-mail address of sender, sender's name, SSRC of associated RTP stream Provide mapping between the SSRC and the user/host name

RTCP: Stream Synchronization Real-Time Control Protocol (RTCP) - Stream Synchronization RTCP: Stream Synchronization RTCP can synchronize different media streams within a RTP session E.G., Videoconferencing application: each sender generates one RTP stream for video, one for audio. Timestamps in RTP packets tied to the video, audio sampling clocks Not tied to wall-clock time Each RTCP sender-report packet contains (for most recently generated packet in associated RTP stream): Timestamp of RTP packet Wall-clock time for when packet was created Receivers uses association to synchronize playout of audio, video

SIP: Session Initiation Protocol Voice over IP (VoIP) Recovery From Packet Loss Content Distribution Networks Real-Time Protocol (RTP) Lecture 10 SIP: Session Initiation Protocol

SIP: Session Initiation Protocol [RFC 3261] Session Initiation Protocol (SIP) SIP: Session Initiation Protocol [RFC 3261] Long-term vision: All telephone calls, video conference calls take place over internet People identified by names or e-mail addresses, rather than by phone numbers Can reach callee (if callee so desires), no matter where callee roams, no matter what IP device callee is currently using

Session Initiation Protocol (SIP) - Services SIP provides mechanisms for call setup: For caller to let callee know she wants to establish a call So caller, callee can agree on media type, encoding To end call Call management: Add new media streams during call Change encoding during call Invite others Transfer, hold calls Determine current IP address of callee: Maps mnemonic identifier to current IP address Name translation & user location are provides by SIP servers: SIP registrar server SIP proxy server SIP messages can be sent over TCP or UDP Media can be sent over RTP or some other protocol

Conclusion Conclusion VoIP requires end-to-end delay less than 150 msec and packet loss rate between less than10%. Playout can be used to mitigate the effect of delay & delay jitter Forward error correction and interleaving schemes can be used to mitigate the effect of packet loss CDN: bring content closer to clients Real Time Protocol (RTP) specifies structure for packets carrying audio, video data RTP doesn’t provide QoS guarantees RTP provides transport-layer interface that extends UDP: Port numbers, IP addresses Payload type identification Packet sequence numbering Time-stamping Session Initiation Protocol (SIP) provides mechanisms for call setup

References References Computer Networking: A Top-Down Approach Featuring the Internet by James Kurose and Keith Ross, Addison Wesley, 2012 (chapter 7 ) Quality of Service for Voice over IP – Cisco Systems A Transport Protocol for Real-Time Applications(RFC3550) Session Initiation Protocol (RFC3261)