Multimedia Protocols. Foreleser: Carsten Griwodz Mai INF-3190: Multimedia Protocols

Transcription

1 Multimedia Protocols Foreleser: Carsten Griwodz Mai INF-3190: Multimedia Protocols

2 Media! Medium: "Thing in the middle! here: means to distribute and present information! Media affect human computer interaction! The mantra of multimedia users! Speaking is faster than writing! Listening is easier than reading! Showing is easier than describing 11. Mai INF-3190: Multimedia Protocols

3 Dependence of Media! Time-independent media! Text! Graphics! Discrete media! Time-dependent media! Audio! Video! Animation! Continuous media! Interdependant media! Multimedia! "Continuous" refers to the user s impression of the data, not necessarily to its representation! Combined video and audio is multimedia - relations must be specified 11. Mai INF-3190: Multimedia Protocols

4 High Data Volume! Throughput! Higher volume than for traditional data! Longer transactions than for traditional data! Requires! Performance and bandwidth! Resource management techniques! Compression! Typical values! Uncompressed video: Mbit/s! Uncompressed audio (CD): 1.4 Mbit/s! Uncompressed speech: 64 Kbit/s! Compressed audio & video (VoD): down to Mbit/s! Compressed audio & video (Conf.): down to 128 Kbit/s! Compressed speech: down to 6.2 Kbit/s 11. Mai INF-3190: Multimedia Protocols

5 Compression General Requirements 11. Mai INF-3190: Multimedia Protocols

6 Example: MPEG-1! International Standard: Moving Pictures Expert Group! Compression of audio and video for playback (1.5 Mbit/s)! Real-time decoding! Sequence of I-, P-, and B-Frames I-Frames intra-coded B-Frames bi-directionally coded P-Frames predictive coded 11. Mai INF-3190: Multimedia Protocols

7 MPEG (Moving Pictures Expert Group)! Frames can be dropped! In a controlled manner! Frame dropping does not violate dependancies! Example: B-frame dropping in MPEG Mai INF-3190: Multimedia Protocols

8 Multimedia Networking! Internet without network QoS support! Internet applications must cope with networking problems! Application itself or middleware! "Cope with" means either "adapt to" or "don t care about! "Adapt to" must deal with TCP-like service variations! "Don t care about" approach is considered "unfair! "Don t care about" approach cannot work with TCP! Internet with network QoS support! Application must specify their needs! Internet infrastructure must change negotiation of QoS parameters! Routers need more features! Keep QoS-related information! Identify packets as QoS-worthy or not! Treat packets differently keep routing consistent 11. Mai INF-3190: Multimedia Protocols

9 Non-QoS Multimedia Networking Application Layer Framing & Integrated Layer Processing 11. Mai INF-3190: Multimedia Protocols

10 Multimedia Content Processing! Problem: optimize transport of multimedia content! It is application dependent and specific! Application-layer processing has high overhead! Application processes data as it arrives from the network! Impact of lost and mis-ordered data! Transport layer tries to recover from error! Prevents delivery of data to application! Prevents immediate processing as data arrives! Application must stop processing! Transport layer ignores error! Application experiences processing failures! Application must stop processing 11. Mai INF-3190: Multimedia Protocols

11 Application Level Framing [Clark/Tennenhouse 1990]! Give application more control! Application understands meaning of data! Application should have the option of dealing with a lost data! Reconstitute the lost data (recompute/buffer by applications)! Ignore the lost data! Application level framing! Application breaks the data into suitable aggregates! Application Data Units (ADUs)! Lower layers preserve the ADU frame boundaries! ADU takes place of packet as the unit of manipulation 11. Mai INF-3190: Multimedia Protocols

12 ALF: Application Data Units! ADUs become the unit of error recovery! Should be upper bounded! Loss of large ADUs is more difficult to fix! Lower bounded! Application semantics define smallest sensible unit! Small ADUs mean larger protocol overhead! Segmentation/reassembly! Try to avoid! ADU name! Sender computes a name for each ADU! Receiver uses name to understand its place in the sequence of ADUs! Receiver can process ADUs out of order 11. Mai INF-3190: Multimedia Protocols

13 Integrated Layer Processing! Layered engineering is not fundamental! Assignment of functions to layers in OSI is not following fundamental principles! Specific application may work better with different layering of functions or no layering at all! Sequential processing through each layer " Not an efficient engineering " Processing all functions at once saves computing power! Integrated Layer Processing! Vertical integration! Performing all the manipulation steps in one or two integrated processing loops, instead of serially 11. Mai INF-3190: Multimedia Protocols

14 Integrated Layer Processing! Ordering constraint! Data manipulation can only be done after specific control steps! Data manipulation can only be done once the data unit is in order! Layered multiplexing (extract the data before it can be demultiplexed)! Minimize inter-layer ordering constraints imposed on implementors! Implementors know best which data must be ordered! Drawback: complex design due to fully customized implementation 11. Mai INF-3190: Multimedia Protocols

15 Non-QoS Multimedia Networking RTP Real-Time Transfer Protocol 11. Mai INF-3190: Multimedia Protocols

16 Real-time Transport Protocol (RTP)! Real-time Transport Protocol (RTP)! RFC 3550 (replaces RFC 1889)! Designed for requirements of real-time data transport! NOT real-time! NOT a transport protocol! Two Components! Real-Time Transfer Protocol (RTP)! RTP Control Protocol (RTCP)! Provides end-to-end transport functions! Scalable in multicast scenarios! Media independent! Mixer and translator support! RTCP for QoS feedback and session information 11. Mai INF-3190: Multimedia Protocols

17 Real-time Transport Protocol (RTP)! No premise on underlying resources! layered above transport protocol! no reservation / guarantees! Integrated with applications application media encapsulation RTP RTCP! RTP follows principles of! Application Level Framing and TCP UDP! Integrated Layer Processing IPv4/6 ST-2 ATM Ethernet AAL5 ATM 11. Mai INF-3190: Multimedia Protocols

18 RTP! RTP services are! Sequencing! Synchronization! Payload identification! QoS feedback and session information! RTP supports! Multicast in a scalable way! Generic real-time media and changing codecs on the fly! Mixers and translators to adapt to bandwidth limitations! Encryption! RTP is not designed for! Reliable delivery! QoS provision or reservation 11. Mai INF-3190: Multimedia Protocols

19 RTP Functions! RTP with RTCP provides! Support for transmission of real-time data! Over multicast or unicast network services! Functional basis for this! Loss detection sequence numbering! Determination of media encoding! Synchronization timing! Framing - guidelines in payload format definitions! Encryption! Unicast and multicast support! Support for stream translation and mixing (SSRC; CSRC) 11. Mai INF-3190: Multimedia Protocols

20 RTP Packet Format Typical IETF RFC bit-exact representation a longword (32 bit) a byte V=2 P X CC M PT SEQ TST synchronization source (SSRC) identifier +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ contributing source (CSRC) identifiers header extension payload (audio, video,...) Mai INF-3190: Multimedia Protocols

21 Version number, Always 2 RTP Packet Format Padding indicator bit if set, number of padding bytes is in last byte of payload Header extension bit True if header extension is present V=2 P X CC M PT SEQ TST synchronization source (SSRC) identifier +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ contributing source (CSRC) identifiers Marker header bit extension Meaning depends on payload profile, payload (audio, video,...)... 7 bit payload type Allows identification of the payload s content type e.g. frame boundary bit CSRC count, indicates the number of contributing sources in the header 11. Mai INF-3190: Multimedia Protocols

22 RTP Packet Format 32 bit timestamp 16 bit sequence number Header extension multiples of 32 bit 32 bit SSRC Synchronization source identifier, a random number identifying the sender V=2 P X CC M PT SEQ TST synchronization source (SSRC) identifier +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ contributing source (CSRC) identifiers header extension payload (audio, video,...) Several 32 bit CSRC Contribution source identifier, the number is indicated by CC A mixer copies the original sources SSRCs here Mai INF-3190: Multimedia Protocols

23 RTP Architecture Concepts! Integrated Layer Processing! Typical layered! Data units sequentially processed by each layer! Integrated layer processing! Adjacent layers tightly coupled! Therefore, RTP is not complete by itself: requires application-layer functionality/information in header Marker bit Meaning depends on payload profile, e.g. frame boundary 7 bit payload type Allows identification of the payload s content type V=2 P X CC M PT SEQ TST synchr onizati on sour ce (SSR C) iden tifier +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ contr ibuting source (CSRC) identi fiers bit sequence number header extension payload (audio, video,...) bit timestamp 11. Mai INF-3190: Multimedia Protocols

24 RTP Packet Format! Relatively long header (>40 bytes)! overhead carrying possibly small payload! header compression! other means to reduce bandwidth (e.g. silence suppression)! No length field! Exactly one RTP packet carried in UDP packet! Can use TCP or ATM AAL5! do-it-yourself packaging! Header extensions for payload specific fields possible! Specific codecs! Error recovery mechanisms 11. Mai INF-3190: Multimedia Protocols

25 RTP Profile (RFC 1890)! Set of standard encodings and payload types! Audio: e.g. PCM-u, GSM, G.721! Video: e.g. JPEG, H.261! Number of samples or frames in RTP packet! Sample-based audio: no limit on number of samples! Frame-based audio: several frames in RTP packet allowed! Clock rate for timestamp! Packetized audio: default packetization interval 20 ms! Video: normally 90 khz, other rates possible 11. Mai INF-3190: Multimedia Protocols

26 RTP Profiles! Payload type identification! RTP provides services needed for generic A/V transport! Particular codecs with additional requirements! Payload formats defined for each codec: syntax and semantic of RTP payload! Payload types! Static: RTP AV profile document! Dynamic: agreement on per-session basis! Profiles and Payload Formats in RTP Framework Additional Profiles AV Profile RTP / RTCP Payload Formats Dynamic Payload Types PT mapping outside RTP (e.g. SDP) 11. Mai INF-3190: Multimedia Protocols

27 RTP Profiles! General! Associated with a media type.! Provides association between PT field and specific media format! Defines sampling rate of timestamp! May also define or recommend a definition for the marker bit! Video Profile! Marker bit recommended to mean last packet associated with a timestamp! Timestamp clock: Hz! Defines PT mapping for a number of different video encoding types 11. Mai INF-3190: Multimedia Protocols

28 RTP Profiles! Audio Profile! Marker bit set on the first packet after a silence period where no packets sent! Timestamp equals sampling rate! Recommends 20ms minimum frame time! Recommends that samples from multiple channels be sent together! Defines PT for a number of different audio encoding types 11. Mai INF-3190: Multimedia Protocols

29 RTP Profile for MPEG Video Payload GOP header Frame headers 11. Mai INF-3190: Multimedia Protocols

30 RTP Profile for MPEG Video Payload! Fragmentation rules! Video sequence header! if present, starts at the beginning of an RTP packet! GOP sequence header! Either at beginning of RTP packet! Or following video sequence header! Picture header! Either at beginning of RTP packet! Following GOP header! No header can span packets! Marker Bit! Set to 1 if packet is end of picture 11. Mai INF-3190: Multimedia Protocols

31 RTP Profile for MPEG Video Payload! MPEG-1 Video specific payload header! MBZ MPEG Video Profile MBZ TR MBZ S B E P BFC FFC FBV FFV! Must be zero! TR! Temporal reference! The same number for all packets of one frame! For ordering inside an MPEG GOP! S! 1 is sequence header is in this packet! B! 1 if payload starts with new slice! E! 1 if last byte of payload is end of slice! P! 3 bits that indicate picture type (I,P, or B)! FBV, BFC, FFC, FFC! Indicate how a P or B frame is related to other I and P frames 11. Mai INF-3190: Multimedia Protocols

32 RTP Quality Adaptation Application Application Decoding Encoding Encoding Decoding RTP RTCP RTCP RTP UDP/IP UDP/IP! Component interoperations for control of quality! Evaluation of sender and receiver reports! Modification of encoding schemes and parameters! Adaptation of transmission rates! Hook for possible retransmissions (outside RTP) 11. Mai INF-3190: Multimedia Protocols

33 RTP Control Protocol (RTCP)! Companion protocol to RTP (tight integration with RTP)! Monitoring! of QoS! of application performance! Feedback to members of a group about delivery quality, loss, etc.! Sources may adjust data rate! Receivers can determine if QoS problems are local or network-wide! Loose session control! Convey information about participants! Convey information about session relationships! Automatic adjustment to overhead! report frequency based on participant count! Typically, RTP does... means RTP with RTCP does Mai INF-3190: Multimedia Protocols

34 RTCP Packets R SR / RR SDES BYE APP! Several RTCP packets carried in one compound packet! RTCP Packet Structure Compound (UDP) Packet! SR Sender Report (statistics from active senders: bytes sent -> estimate rate)! RR Receiver Report (statistics from receivers)! SDES Source Descriptions (sources as chunks with several items like canonical names, , location,...)! BYE explicit leave! APP extensions, application specific 11. Mai INF-3190: Multimedia Protocols

35 RTCP Sender / Receiver Reports! Sender report! Sender Information! Timestamps! Packet Count, Byte Count! List of statistics per source! Receiver report! For each source! Loss statistics! Inter-arrival jitter! Timestamp of last SR! Delay between reception of last SR and sending of RR! Analysis of reports! Cumulative counts for short and long time measurements! NTP timestamp for encoding- and profile independent monitoring Header Sender Information Reception Report... Reception Report Profile Specific Extensions Header Reception Report... Reception Report Profile Specific Extensions 11. Mai INF-3190: Multimedia Protocols

36 RTP Mixer! Mixer! Reconstructs constant spacing generated by sender! Translates audio encoding to a lower-bandwidth! Mixes reconstructed audio streams into a single stream! Resynchronizes incoming audio packets! New synchronization source value (SSRC) stored in packet! Incoming SSRCs are copied into the contributing synchronization source list (CSRC)! Forwards the mixed packet stream! Useful in conference bridges 11. Mai INF-3190: Multimedia Protocols

37 RTP Translator MPEG Sink MPEG Source ATM Protocol Translator UDP Profile Translator H.263 Sink! Translation between protocols! e.g., between IP and ST-2! Two types of translators are installed! Translation between encoding of data! e.g. for reduction of bandwidth without adapting sources! No resynchronization in translators! SSRC and CSRC remain unchanged 11. Mai INF-3190: Multimedia Protocols

38 RTP Identifiers SSRC chosen by sender S1 SSRC chosen by mixer M1 S1 S3 S1:10 S3:19 M1 M1:33 (10,1) M1:33 (10,1) T1 S4:13 M2 M2:17 (19,13,33) R1 S2:1 S4:13 S2 S4 Translators keep SSRCs and CSRCs CSRCs from mixed sources S1 and S2 CSRCs contain previous SSRCs, but not previous CSRCs 11. Mai INF-3190: Multimedia Protocols

39 Protocol Development! Changes and extensions to RTP! Scalability to very large multicast groups! Congestion Control! Algorithms to calculate RTCP packet rate! Several profile and payload formats! Efficient packetization of Audio / Video! RTCP-based retransmission! Loss / error recovery 11. Mai INF-3190: Multimedia Protocols

40 Non-QoS Multimedia Networking Signalling Protocols: RTSP and SIP 11. Mai INF-3190: Multimedia Protocols

41 Signaling Protocols! Applications differ! Media delivery controlled by sender or receiver! Sender and receiver meet before media delivery! Signaling should reflect different needs! Media-on-demand! Receiver controlled delivery of content! Explicit session setup! Internet telephony and conferences:! Bi-directional data flow, live sources! (mostly) explicit session setup, mostly persons at both ends! Internet broadcast! Sender announces multicast stream! No explicit session setup 11. Mai INF-3190: Multimedia Protocols

42 Real-Time Streaming Protocol (RTSP)! Internet media-on-demand! Select and playback streaming media from server! Similar to VCR, but! Potentially new functionality! Integration with Web! Security! Varying quality! Need for control protocol! Start, stop, pause,! RTSP is also usable for! Near video-on-demand (multicast)! Live broadcasts (multicast, restricted control functionality)! Mai INF-3190: Multimedia Protocols

43 RTSP Approach! In line with established Internet protocols! Similar to HTTP 1.1 in style! Uses URLs for addressing: rtsp://video.server.com:8765/videos/themovie.mpg! Range definitions! Proxy usage! Expiration dates for RTSP DESCRIBE responses! Other referenced protocols from Internet (RTP, SDP)! Functional differences from HTTP! Data transfer is separate from RTSP connection! typically via RTP! Server maintains state setup and teardown messages! Server as well as clients can send requests 11. Mai INF-3190: Multimedia Protocols

44 RTSP Features! Rough synchronization! Media description in DESCRIBE response! Timing description in SETUP response! Fine-grained through RTP sender reports! Aggregate and separate control of streams possible! Virtual presentations! Server controls timing for aggregate sessions! RTSP Server may control several data (RTP) servers! Load balancing through redirect at connect time! Use REDIRECT at connect time! Caching! Only RTSP caching so far! Data stream caching is under discussion 11. Mai INF-3190: Multimedia Protocols

45 RTSP Methods OPTIONS DESCRIBE ANNOUNCE SETUP RECORD PLAY PAUSE REDIRECT TEARDOWN SET_PARAMETER GET_PARAMETER C S C S C S C S C S C S C S C S C S C S C S C S determine capabilities of server/client get description of media stream announce new session description create media session start media recording start media delivery pause media delivery redirection to another server immediate teardown change server/client parameter read server/client parameter 11. Mai INF-3190: Multimedia Protocols

46 RTSP Integration HTTP server HTTP GET presentation description file RTSP server RTSP SETUP RTSP OK RTSP PLAY RTSP OK RTSP TEARDOWN RTSP OK RTSP plug-in data source media server RTP VIDEO RTP AUDIO AV subsystem web browser 11. Mai INF-3190: Multimedia Protocols

47 Session Initiation Protocol (SIP)! Lightweight generic signaling protocol! Internet telephony and conferencing! Call: association between number of participants! Signaling association as signaling state at endpoints (no network resources)! Several services needed! Name translation! User location! Feature negotiation! Call control! Changing features 11. Mai INF-3190: Multimedia Protocols

48 SIP Basics! Call user! Re-negotiate call parameters! Forwarding (manual and automatic)! Call center! Supports personal mobility (change of terminal)! Through proxies or redirection! Terminate / transfer calls! ASCII (readable) protocol SIP vs. H.323! Similarities (request/response, proxies...)! Differences (server state, server may initiate actions...)! Control, location and media description (via SDP)! Extensible towards! Usage for IP-IP, POTS-IP, inter-gateway interaction with firewalls, billing system,...! Different modes! Proxy mode! Redirect mode 11. Mai INF-3190: Multimedia Protocols

49 SIP Operation Proxy Mode Location Server Site A 1. Invite u@domain 7. Ok 2. Where? 3. user@host 4. Invite user@host 6. Ok 5. Ring User with symbolic name calls another 8. ACK u@domain 11. Ok Proxy Mode 9. ACK user@host 10. Ok Site B! Proxy forwards requests! Possibly in parallel to several hosts! Cannot accept or reject call! Useful to hide location of callee 11. Mai INF-3190: Multimedia Protocols

50 SIP Operation Redirect Mode Location Server Site A User with symbolic name calls another 1. Invite u@domain 4. Moved temporarily Location: user@domain2 5. ACK u@domain 2. Where? 3. user@host Redirect Mode 6. Invite user@domain2 7. Ring 7. Ok 8. ACK user@domain2 Site B 11. Mai INF-3190: Multimedia Protocols

51 SIP Methods! Basic Methods (RFC 2543) TABLE! Additional Methods (partially standardized)! INFO: carry information between User Agents! REFER: ask someone to send an INVITE to another participant! SUBSCRIBE: request to be notified of specific event! NOTIFY: notification of specific event 11. Mai INF-3190: Multimedia Protocols

52 RTP! RTP services are! Sequencing! Synchronization! Payload identification! QoS feedback and session information! RTP supports! Multicast in a scalable way! Generic real-time media and changing codecs on the fly! Mixers and translators to adapt to bandwidth limitations! Encryption! RTP is not designed for! Reliable delivery! QoS provision or reservation 11. Mai INF-3190: Multimedia Protocols