Internet Services & Protocols Multimedia Applications, Voice over IP

Transcription

1 Department of Computer Science Institute for System Architecture, Chair for Computer Networks Internet Services & Protocols Multimedia Applications, Voice over IP Dipl.-Inform. Stephan Groß Room: GRU314 Dresden, May

2 What are multimedia applications? Classes of networked multimedia applications Real time interactive Audio/ Video Internet telephony, video conferences Streaming live Audio/ Video digital Radio (DAB, DRM), digital TV Streaming stored Audio/ Video on Demand Video Business TV to the Desktop, Distance Learning Fundamental characteristics Typically delay sensitive end-to-end delay delay jitter But loss tolerant: infrequent losses cause minor glitches Antithesis of data, which are loss intolerant but delay tolerant. Stephan Groß, May Internet Services & Protocols 2

3 Application requirements application Data transfer Web documents Realtime audio/video Stored audio/video Interactive audio/video packet lost no no no tolerant tolerant tolerant bandwidth elastic elastic elastic audio: 5kbps- 1Mbps video:10kbps- 5Mbps time sensitive no no no yes, a few 100 ms yes, a few s Yes, a few 100 ms traditional applications multimedia applications Stephan Groß, May Internet Services & Protocols 3

4 Multimedia Requirements for LANs / WANs If audio or video services are intended to be integrated in traditional data networks, the network must be capable for: Guaranteed transmissions Quality of Service! Priories of audio packet against data packets Standardised interfaces Availability and reliability of such communication systems Data security is getting more important for audio/voice transmissions over the Internet (tap-proof ) Stephan Groß, May Internet Services & Protocols 4

5 Multimedia over Today's Internet TCP/UDP/IP: best-effort service no guarantees on delay, loss?????? But you said multimedia apps requires QoS and level of performance to be effective!????? Today s Internet multimedia applications use application-level techniques to mitigate (as best possible) effects of delay, loss Stephan Groß, May Internet Services & Protocols 5

6 How should the Internet evolve to better support better multimedia? Integrated services philosophy: Fundamental changes in Internet so that apps can reserve end-to-end bandwidth Requires new, complex software in hosts & routers Laissez-faire no major changes more bandwidth when needed content distribution, application-layer multicast Differentiated services philosophy: Stephan Groß, May Internet Services & Protocols 6 Fewer changes to Internet infrastructure, yet provide 1st and 2nd class service. What s your opinion?

7 End-to-End Delay E2E-delay is the sum of delay experienced by packets due the processing in end systems, interim systems (router switches etc.) and on transmission line. Stephan Groß, May Internet Services & Protocols 7

8 Jitter A packet pair s jitter is the difference between the transmission time gap and the receive time gap Sender: Pkt i Pkt i+1 Receiver: Pkt i Pkt i+1 S i S i+1 jitter Time R i R i+1 Desired time-gap: S i+1 - S i Received time-gap: R i+1 - R i Jitter between packets i and i+1: (R i+1 - R i ) - (S i+1 - S i ) Stephan Groß, May Internet Services & Protocols 8

9 Jitter Compensation packets transmitting constant bit rate (sender) playback constant bit rate (receiver) packets generated packets received loss playout schedule p' - r playout schedule p - r delayed playout to compensate jitter r p p' time Stephan Groß, May Internet Services & Protocols 9

10 Packet Loss Problem: Internet might lose / excessively delay packets making them unusable for the session arrival time: Pkt i Pkt i+1 Pkt i+3 app deadline: i i+1 i+2 i+3 usage status:, i used, i+1 late, i+2 lost, i+3 used,... Solution step 1: Design app to tolerate some loss Solution step 2: Design techniques to recover some lost packets within application s time limits Stephan Groß, May Internet Services & Protocols 10

11 Reducing Packet Loss w/in Time Bounds Problem: packets must be recovered prior to application deadline Retransmission unacceptable for real time apps Solution: Forward Error Correction on packet level (FEC); Example: MQS Mixed Quality Streams MQS: redundant duplicates of packets; despite of loss, playback possible through redundant packet, even with lower quality One redundant packet per packet single losses compensable Mixing (piggypack) stream with lower quality Stephan Groß, May Internet Services & Protocols 11

12 Bursty Loss Many codecs can recover from short (1 or 2 packet) loss outages Bursty loss (loss of many pkts in a row) creates long outages: quality deterioration more noticeable FEC provides less benefit in a bursty loss scenario (e.g., consider 30% loss in bursts 3 packets long) Stephan Groß, May Internet Services & Protocols 12

13 Interleaving To reduce effects of burstiness, reorder packet transmission Example: break down a 20 ms audio packet into smaller parts of 5 ms each and interleave them Despite of packet loss: partly filled audio parts, missing parts can be interpolated No redundancy, but induces buffering and additional delay; realtime requirements cannot be satisfied if necessary Stephan Groß, May Internet Services & Protocols 13

14 IP Telephony aka Voice over IP (VoIP) Circuit switched telephony (ISDN) Circuit switched telephony Stephan Groß, May Internet Services & Protocols 14

15 Session Initiation Protocol (SIP) Layer 7 protocol Application Layer Comes from IETF Purpose: Signalling of interactive sessions in the Internet Interactive Communication e.g. Multimedia-conferences Internet-Telephony (VoIP) Tele working and teaching Signalling aspects User localisation recognizing of user capabilities Test of user availability Connection establishment Connection negotiation Stephan Groß, May Internet Services & Protocols 15

16 Some Facts about SIP SIP is a Signalling protocol, so it does not define how multimedia streams should be encoded and transported: Real-time Transport Protocol (RTP) is used for audio/video transmissions. SIP is usually implemented on top of UDP (or on top of TCP, too) Signalling messages are generally small and sent infrequently For every request sent, a response is to be received. The response can be used as acknowledgement. To avoid the need of a centralized directory sever, SIP uses SIP proxies to route communication messages (comparable with H.323 gatekeepers) and A registration server is used to distribute and announce registrations Uses URL similar addresses/syntax and HTML-elements in messages, so it can be better combined with web technology. Stephan Groß, May Internet Services & Protocols 16

17 The Architectural View of SIP User Agent Client (UAC) End systems in SIP-based systems UAC sends a request to an UAS User Agent Server (UAS) Receives requests from clients Accepts and answers to a request, reject a request or routes it to an another Proxy Server Primary task: transmitting SIP - protocol elements via routing Negotiator between client and server While routing SIP-messages, they can pass more than one SIP-Proxies Stephan Groß, May Internet Services & Protocols 17

18 The Architectural View of SIP ff. Redirect Server Acts like an UAS Responses to requests of UACs with a redirect information, enabling the UAC to sent the message to an alternative address Do not sent messages automatically Registrar Receives REGISTER-messages and forwards these messages to a Location Service, which stores and returns possible locations for users Stephan Groß, May Internet Services & Protocols 18

19 The Functional View SIP Services Setting up a call Provides mechanisms for caller to let callee know she wants to establish a call Provides mechanisms so that caller and callee can agree on media type and encoding. Provides mechanisms to end call. Determine current IP address of callee Maps mnemonic identifier to current IP address Call management Add new media streams during call Change encoding during call Invite others Transfer and hold calls Stephan Groß, May Internet Services & Protocols 19

20 SIP Example: Setting up a Call to a known IP address A l i c e B o b Alice s SIP INVITE message includes her portnumber & IP address. Alice prefers to receive PCM (AVP 0). Bobs 200 OK message shows his port, IP address & GSM as his favourite codec INVITE bob@ c=in IP m=audio RTP/AVP 0 port 5060 port OK c=in IP m=audio RTP/AVP ACK port 5060 B o b ' s t e r m i n a l r i n g s SIP messages are sent out of band. Audio data should be sent using RTP. Default SIP port is p o r t G S M L a w a u d i o p o r t t i m e t i m e Stephan Groß, May Internet Services & Protocols 20

21 Setting up a call (more) Codec negotiation: Suppose Bob doesn t have PCM ulaw encoder. Bob will instead reply with 606 Not Acceptable Reply and list encoders he can use. Alice can then send a new INVITE message, advertising an appropriate encoder. Rejecting the call Bob can reject with replies busy, gone, payment required, forbidden. Media can be sent over RTP or some other protocol. Stephan Groß, May Internet Services & Protocols 21

22 Example of a SIP message INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP From: sip:alice@hereway.com To: sip:bob@domain.com Call-ID: a2e3a@pigeon.hereway.com Content-Type: application/sdp Content-Length: 885 c=in IP m=audio RTP/AVP 0 Notes: HTTP message syntax sdp = session description protocol Call-ID is unique for every call. Here we don t know Bob s IP address. Intermediate SIP servers will be necessary. Alice sends and receives SIP messages using the SIP default port number Alice specifies in Via: header that SIP client sends and receives SIP messages over UDP Stephan Groß, May Internet Services & Protocols 22

23 Name Translation and User Location Caller wants to call callee, but only has callee s name or address. Need to get IP address of callee s current host: user moves around DHCP protocol user has different IP devices (PC, PDA, car device) Result can be based on: time of day (work, home) caller (don t want boss to call you at home) status of callee (calls sent to voic when callee is already talking to someone) Service provided by SIP servers: SIP registrar server SIP proxy server Stephan Groß, May Internet Services & Protocols 23

24 SIP Registrar When Bob starts SIP client, client sends SIP REGISTER message to Bob s registrar server (similar function needed by Instant Messaging) Register Message: REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP From: sip:bob@domain.com To: sip:bob@domain.com Expires: 3600 Stephan Groß, May Internet Services & Protocols 24

25 SIP Proxy Alice sends invite message to her proxy server contains address Proxy responsible for routing SIP messages to callee possibly through multiple proxies. Callee sends response back through the same set of proxies. Proxy returns SIP response message to Alice contains Bob s IP address Note: proxy is analogous to local DNS server Stephan Groß, May Internet Services & Protocols 25

26 Example using SIP in VoIP calls (1) Jim sends an INVITE message to Umass SIP proxy. (2) Proxy forwards request to upenn registrar server. (3) Upenn Server responses with a redirect (use keith@eurecom.fr!) (4) Umass proxy sends INVITE to Eurecom registrar. (5) Eurecom registrar routes INVITE to (Keiths SIP client). (6-8) SIP response is sent back. (9) Audio data are exchanged directly between clients. S I P p r o x y u m a s s. e d u S I P c l i e n t S I P r e g i s t r a r u p e n n. e d u S I P r e g i s t r a r e u r e c o m. f r 6 5 S I P c l i e n t Stephan Groß, May Internet Services & Protocols 26

27 VoIP uses RTP Real-time Transport Protocol (RTP) RFC 1889/1890 RTP provides: End-to-end transport, intended for application, which transmit real time traffic like audio, video or simulation data using unicast or multicast connections RTP usually uses UDP for an efficient and less delayed data transmission RTP does not provide Signalling Resource reservation, QoS, guaranteed delivery/ sequence (RSVP) Stephan Groß, May Internet Services & Protocols 27

28 RTP Functions Identification of Data (payload type) Sequence numbers Restoration of packet sequence Detection of packet loss Time stamps Intra-media synchronisation: to remove jitter, delay Inter-media synchronisation: lip synchronisation Connection monitoring (through RTCP) Quality feedback (QoS) Sender based rate adaption for RTP-sessions Stephan Groß, May Internet Services & Protocols 28

29 Real-Time Control Protocol (RTCP) Works in conjunction with RTP. Each participant in RTP session periodically transmits RTCP control packets to all other participants. Each RTCP packet contains sender and/or receiver reports report statistics useful to application Statistics include number of packets sent, number of packets lost, interarrival jitter, etc. Feedback can be used to control performance Sender may modify its transmissions based on feedback Stephan Groß, May Internet Services & Protocols 29

30 RTCP continued For an RTP session there is typically a single multicast address; all RTP and RTCP packets belonging to the session use the multicast address. RTP and RTCP packets are distinguished from each other through the use of distinct port numbers. To limit traffic, each participant reduces his RTCP traffic as the number of conference participants increases. Stephan Groß, May Internet Services & Protocols 30

31 RTCP Packets Receiver report packets: fraction of packets lost, last sequence number, average interarrival jitter. Sender report packets: SSRC of the RTP stream, the current time, the number of packets sent, and the number of bytes sent. Source description packets: address of sender, sender's name, SSRC of associated RTP stream. Provide mapping between the SSRC and the user/host name. Stephan Groß, May Internet Services & Protocols 31

32 Synchronization of Streams RTCP can synchronize different media streams within a RTP session. Consider videoconferencing app for which each sender generates one RTP stream for video and one for audio. Timestamps in RTP packets tied to the video and audio sampling clocks not tied to the wall-clock time Each RTCP sender-report packet contains (for the most recently generated packet in the associated RTP stream): timestamp of the RTP packet wall-clock time for when packet was created. Receivers can use this association to synchronize the playout of audio and video. Stephan Groß, May Internet Services & Protocols 32

33 Conclusion Internet was build for data applications does not support multimedia applications very well There several techniques to overcome drawbacks like packet delay, jitter of loss VoIP uses SIP for signalling and RTP for data transmission Currently missing: streaming of live and stored video/audio Postponed to another group homework Stephan Groß, May Internet Services & Protocols 33